What prevents the hacker from cloning the whole web-page of, say, facebook.com login and phish users for credentials this way? This is not a hyphotetical thing, Kali Linux even bundles a utility program for that.
Compared to that, one icon, that is the same as that of the company, is not that threatening.
Not only that, but if you consider a sign in form that wouldn't have a logo, it would be way easier to trick user into putting their credentials in, because the user wouldn't be able to differentiate them. Also OAuth is always branded AFAIK.
Users may also notice discrepancies in the logo, if it was cloned poorly. Though I can't think of a way someone couldn't forge a logo given all the possibilities. Adobe Illustrator can trace images into svg and there's plenty of companies' svg logos just in the google search.
How is it not applicable when the thing at question is rendering text and rendering is the core of game development? This argument is stupid. Do you have to be a slowpoke to develop commercial apps?
My point is that a UI that meets the needs of as many users as possible, including things like internationalization and accessibility, is much more complex than a typical game UI. That complexity drives developers to use abstractions that often make it much more difficult to optimize. And in the big picture, support for these things that add complexity is often more important than top-speed rendering.
Games are typically much better at internationalization and accessibility than developer tooling though. For example this new windows console doesn't have either, but all big games gets translated to and handles text from languages all over the world.
Video games often have an international audience and go to great lengths to support accessibility and multiplatform support, ie. supporting both tablet and desktop. It's laughable how bad many enterprise UIs are that fail to handle different locales, or issues displaying right-to-left text and assuming everyone is using an English speaking standard desktop environment, whereas many indie games manage to handle these things very well.
Games usually handle internationalization and accessibility much better than most software.
This includes audio localization (something no 'Enterprise' software has ever needed AFAIK), and multiple colour palettes for different types of colour blindness.
Sometimes video games are the only software with reasonable localizations I ever find installed in a particular computer.
Does the GP's chosen font work correctly in Windows Terminal, though? If so, then that proves that there is indeed more to a fully functional terminal renderer than refterm covers.
Refterm is a not a full-featured terminal in terms of configurability, but it has all the features needed for rendering. Configuration like: choosing fonts, choosing colors, tabs, whatever, it's misc. features, which are unrelated to rendering. The case here is about rendering and it's exactly what is shite in every terminal emulator.
I don't understand why everyone is arguing about it anyway. Refterm provides a fix, Windows Terminal should simply implement it. Is this dignity or what? Are you not engineers? Should you not prioritise software quality above everything else?
EDIT: Remove argument about ease of development, because refterm is easy.
This bugs me every time. "Wow, this software works so good, but we are not gonna make our software like that, no, we'll stick to our shite implementation."
The fact that Casey Muratori's proposed approach requires the terminal to reimplement the process of correctly mapping characters to glyphs - including stuff like fallbacks to other fonts - is a huge part of the argument for why it's much harder to implement and more complicated than he claims. If it really doesn't do that right for something as simple as a decimal seperator for the font some random HN commenter happened to use, that does tend to suggest the Microsoft employees are in the right here.
The "font some random HN commenter happened to use" is some f****** proportional Calibri. I want to see someone use it in any terminal emulator. Refterm defaults to Cascadia Code, but, fair enough, it doesn't have fallback yet.
Its' description says also: "Reference monospace terminal renderer". "monospace" is there for a reason.
It's worth mentioning though, that Windows Terminal also defaults to Cascadia Code and Cascadia Code was installed automatically on my machine, so it's de-facto the new monospace standard font on Windows starting from 10.
which is exactly the point, the amount of shortcut taken to convert code point to fast graphics make it just a nice hack thrown together and devs were right on preferring the slow but correct approach.
That is a terminal bug and not a rendering bug though, since the problem was that the terminal didn't properly fetch your user settings here. Feeding the same character into the other rendering would cause the same issue.
Nobody said he made a fully functional better terminal, just that the terminal rendering was better and functional. Doing everything needed for a fully functional terminal is a lot of work, but doing everything needed for terminal rendering isn't all that much work.
> Nobody said he made a fully functional better terminal
> The "complaining developer" produced a proof of concept in just two weekends that notably had more features[1] and was more correct than the Windows Terminal!
I have to say though, the responder to the first comment did a bad job at conveying what exactly refterm is... Apparently people falsely think that refterm is a terminal emulator and use it interchangeably with terminal and terminal renderer, while it isn't.
If you were to open refterm once, you'd see a text that explicitly states "DO NOT USE IT AS A TERMNIAL EMULATOR", or something like that (can't open it now to copy exact).
You can’t use a non-monospace font on a tiled space. Like that literally makes no sense. Of course it won’t look right. This is like asking why you can’t use `out` parameters on an inherent async function.
Whether the font is monospace or not isn't really the problem - that causes some aesthetically ugly spacing, but that's to be expected and it's still readable. The big issue is that the code has completely failed to find a glyph for one of the characters used in something as commonplace as a directory listing from the dir command and people expect better than this from font rendering in modern applications.
As far as I understood from the video about refterm the speedup is mostly due to not rendering literally every frame in sequence (after all, who needs that), which is what windows terminal seems to be doing.
That seems like it would be unaffected by correcting font rendering.
This is some schoolyard level stuff right here. The GP isn't using a monospaced font. Who, in the history of terminal emulators, has wanted to use a non-monospaced font in their terminal?
Because it's such an improbable edge case, it seems like it's not relevant to the more general discussion of "does refterm's speed and features actually show that the rendering problem is far easier than the Microsoft developers made it out to be".
The Microsoft terminal doesn't render monospaced fonts, the overwhelmingly common case, nearly as fast as refterm. If rendering variable-width fonts is somehow intrinsically insanely expensive for some reason (which I haven't seen anyone provide good evidence for), then a good implementation would still just take refterm's fast monospaced rendering implementation and use it for monospaced fonts, and a slower implementation for variable-width fonts.
That is - refterm's non-existent variable-width font rendering capabilities do not excuse the Windows terminal's abysmal fixed-width font rendering capabilities.
Wait, what? Your edge case is something that no one would ever (should ever?) do? Are you going to complain about it not rendering scripts fonts correctly either?
Also, it's worth noting that this isn't a compelling argument in the first place because the windows terminal doesn't even come close to rendering readable Arabic, it fucks up emoji rendering, etc – all cases that Casey was able to basically solve after two weekends of working on this.
In my 25 years of software development I've found that I'm rarely able to enumerate what an application should or shouldn't do on my own. Unless the app is extremely simple and has very few options it's incredibly unusual for any individual to understand everything about it. While I don't have a use case where I'd want to use a variable space font in a terminal, that doesn't mean such a case doesn't exist for anyone. Maybe some people want that feature.
Windows Terminal, for some reason, gives users the option to change their font to one that isn't monospaced, so I'd argue that it should render them correctly if the user chooses to do that.
Casey threw something together in a matter of days that had 150% of the features of the Windows Terminal renderer, but none of the bug fixing that goes into shipping a production piece of software.
That screenshot you keep parading around is a small issue with a quick fix. It's not like Casey's approach is inherently unable to deal with punctuation!
You don't discard the entire content of a scientific journal paper because of a typo.
"Sorry Mr Darwin, I'm sure you believe that your theory is very interesting, but you see here on page 34? You wrote 'punctuted'. I think you meant 'punctuated'. Submission rejected!"
In this case, the bug fixing is probably the lion's share of the work though - there's a huge amount of subtle edge cases involved in rendering text, and the Microsoft employees almost certainly know this. And the example that broke it isn't even something particularly obscure. We're literally talking about the output of the dir command, one of the first things someone is likely to do with a terminal window, not displaying correctly. He basically did the easy part of the work and lambasted some Microsoft employees as idiots because they thought it was more complex than that.
In Casey's defense (I'm ambivalent on this one), while the dir command itself isn't obscure, one could argue that using a no-op Unicode character as the digit group separator is an obscure case, at least for an American programmer. But I think your overall point still stands.
You've lost the original point: everyone was pretending this refterm was ready to replace the terminal app, criticizing microsoft for taking the slow but sure approach:
> The "complaining developer" produced a proof of concept in just two weekends that notably had more features[1] and was more correct than the Windows Terminal!
But now apparently pointing out that "MS was right not to want to take shortcut in unicode rendering" morphed into "criticizing in bad faith refterm for not being production ready"
Considering Casey himself puts front and center the disclaimer that this is solely intended to be a reference and goes into as much detail in his videos I don't know where you got this from. I don't think anyone is under the illusion that this is could replace the actual terminal. It's just meant to show that there's a minimum level of performance to be expected for not a huge amount of effort (a couple weekend's worth) and there is no excuse for less.
I haven't changed anything, just downloaded and launched, that's the result. if the term only works with one font why is the software picking a random one from the system conf?
It looks like refterm is hard-coded to use Cascadia Mono, which isn't included in-box with Windows 10. So I don't know what happens if you don't have that font. If that's the only issue, then I think we can let that one go, as refterm is clearly only a proof of concept, and one-time logic for choosing the correct font at startup would presumably have no effect on rendering speed.
It looks like your "Digit grouping symbol" field is empty. I'm sure that's standard in some locales, though not for US English. I don't know how to make that field empty; when I try, Windows says it's invalid. So I wonder if your locale sets that separator to some kind of Unicode character that, in a proper renderer, is equivalent to no character at all. If that's the case, then I'm guessing refterm could handle that character as easily as it handles VT escape codes. But this does lend some weight to the position that Casey was oversimplifying things a bit.
Their settings aren't wrong, just different, likely because of differing standards for digit grouping across locales. So this is a case that refterm clearly doesn't support. This case by itself doesn't invalidate refterm's approach to rendering, but I can see why the team at Microsoft, knowing that there are many such cases, would favor abstraction over the absolute best possible speed.
Some people here mention feature plateaus and completeness of the app. Obvious question is, what should the employer then do? The software is complete, from now on there's only maintenance, which is relatively less work compared to building from scratch, so as a consequence I guess developers should be paid less then? Or like you said, fired?
Obviously the manpower could be just moved to the next project, but what if we look at the worst case scenario? What comes next?
Are there at all such mechanisms that could allow for, say, a team of engineers that maintains a bunch of projects in different companies. If such a team would take a maintenance of a few complete programs, the count of them would make up the difference in pay, e.g. a few mainted apps for a lower pay equal pay for building one app from scratch.
I huge non-tech company, manufacturing company. Our software that is perfectly stable and have no new business requirements fall in this bucket.
There's 2 scenarios
1) The entire dev team truly does move on...and the operations are in charge of the production app (they're in charge, anyways). There's no code changes...just OS, database security patching etc. If there are any code changes for security (i.e. upgrading Struts because Equifax got hacked...) then the business side that owns the app gets some resources. But otherwise it really isn't touched. It does cause some contention because no dev wants to be pulled in to work on those junk. But in the last few years, we have teams who's only job is to work on this kind of stuff. They work on apps that only need a dev team for a few months.
2) A stable app is part of a team. The team doesn't work on it anymore...For example my team previously owned ~8 systems. I think like 6 were mature where it had no new features. A lot of people actually left to other teams because of that - which is an issue in itself. What good dev would hang around? And when a new app or major feature is needed...you're left with stranglers and junior engineers who need to somehow step up.
A great many people are involved in maintaining existing buildings. This isn’t just a gotcha but reveals fundamentally faulty thinking underlying your analogy.
I don’t think it does. Buildings aren’t maintained by construction crews. They’re maintained by facilities teams, and maintenance contractors, the latter of which are hired on an as-needed basis rather than on permanent retainer.
It happens to be the case that software maintenance requires essentially the same skills as software implementation, so we don’t differentiate between the two jobs. And besides that, the nature of what people demand is different: nobody expects a single-family home to suddenly accommodate 50 families, but the equivalent of this is not exactly rare in the world of software.
The big difference is that if a competent plumber looks at a sink, it will take them 30 seconds to figure out. If a competent programmer looks at a new codebase with 30000 lines of code, it will take them 6 months to understand it, and then still be missing 80% of the details.
Yes, sure. For online services, that would be all the people involved with maintaining infrastructure. But my point is that construction workers are no longer needed for that particular building once it's completed. Yet, somehow, apps and websites are never completed. They're always changing for no good reason.
But there are all kinds of code-level changes that end up being necessary, even if you never want any new features. You can't just have sysadmins and expect to run a service over the Internet.
What kinds of changes? Operating systems are also feature-complete and don't need that yearly release cycle. They only need updating if there are new hardware capabilities that need to be exposed to applications. And security patches don't change APIs.
I wonder though, whether b2b software also suffers from this, because such software isn't really made for public recognition and etc. in the first place.
That's true. I feel the urge to use new shiny stuff pretty often, but have no choice but to use old robust solutions, because new ones are just mostly proofs of concepts. This is also extremely true about the whole web-dev thing (the good ol' one JavaScript framework a day).
I guess it just comes down to working ethics. Doctors are a good example. Among them there are people who just do a job, who aren't passionate about the whole saving lives. And those are people that work directly with patients and heal people. Now imagine how bad a situation is when a person doesn't work directly with people and responsibility seems little. Among developers, there are people who are genuinely concerned about quality of the code they produce, but they are a minority. There are far more of those, who came in the field just because that's the next big thing and where the money's at. They just spend their whole day ramming that badly written code in a badly written codebase because manager told them to get it done by the end of the day. They don't see the consequences of their actions.
I read something like "a bunch of developers are controlling data of millions of people" some time ago. It feels relevant. Quite a lot of developers don't realize the scale of impact their software can have on people.
While I said all that, I don't know a single bit about what could be done against such a problem. I guess it's just our nature. It seems to shine in many other areas (politics f.e.) as well.
It's just your general mundane ignorance and wrong values.
But that's exactly what you are doing as a programmer who uses it. If you autocomplete using it and then fix the code, you are literally telling it what it got wrong.
I was responding to "It could start to replace us in 20 years." I think if it can do that, it'll basically be AGI and a lot of things will change in a hurry. I don't think that a tool that can do that is even all that similar to this tool.
