Remind me again, which country started this whole mess?
> what choice do the gulf nations, or even all the asian+european (strait users) nations have?
They can go "yeah, you know, the US has been less than reliable as an ally recently, what with absurd tariffs, saber rattling around greenland, belitteling NATO, etc., and they seem unwilling to change, so we're just gonna pay the piper, and get oil, and make arrangements with the Chinese (aka. the worlds most powerful industry), and if they US doesn't like it, that sounds like a them-problem..."
What's very likely not gonna happen, is other countries fighting the US's war for them. NATO already told trump no, other countries won't give different answers.
And anyone who wants to actually invade Iran...well, let's put it this way: Iran is 3-4 times the size of Afghanistan, with even more difficult terrain, and has a standing army of 600,000 men, with over 300,000 in reserve. They have an air force, are proficient in the manufacture of drones, have a working intelligence network. And they've had 4 decades to dig into defensive positions.
what has already started, is already started -- I agree on Trump being dick, but does that make iran's "making new enemies" a wise move?
> NATO already told trump no, other countries won't give different answers.
of course it said no BEFORE IRAN started the $2M toll (and other countries don't like trump due to tariff-for-everyone)
if the current iran regime was strategically wise, iran should have fired everything it got to Israel, and make the missile interception rate down to 40%. That would have actually showed it's power.
now, with even UAE's missile interception rate of 96%, iran actually showed its missiles are nuisances, not some existential threat.
600,000 men and 300,000 in reserve -- well that would have mattered a lot in medieval wars...
"they have an airforce" -- well do they actually have planes?
"have a working intelligence network" -- hmm...
no you're way way way over-estimating iran
the only strategic move for iran was selecting one specific target (israel) and focusing all its might, not becoming a rambo
Their win condition isn't destroying Israel, its outlasting the American will for the war until a leadership change happens. They aren't the attackers in this war. They need to just defend until America and Israel give up because it is too costly at home.
> its outlasting the American will for the war until a leadership change happens
well even in the best-case scenario (trump impeachment), I highly doubt any democrat president can actually stop at status quo -- rather, the next president has exactly zero choice but to wipe out iran MORE than trump (and call trump a weakling)
just leave Iran be and get out? well he/she could, GIVEN that Iran didn't show its potential to be bully on the gulf states and didn't even think about that $2M toll...
now? well even if a pirate has a sad back story, doesn't mean the navy can leave them be.
by missiling everyone nearby, iran just became too dangerous to nearby neighbors...
by even talking about $2M toll, iran just became too financially dangerous even to strait users... I mean, even if it's "just $2M", what will stop iran from asking $5M, $10M, or even $100M ?
> what has already started, is already started -- I agree on Trump being dick, but does that make iran's "making new enemies" a wise move?
There is no downside on making the Gulf states enemies. Quite to the contrary: they might lobby the USA to end this madness. It's a serious damage to the importance of the USA in the region if it can't or doesn't want to open the strait again, either by force or by making a deal.
When people rewriting open source libs with a bot then come crying to maintainers that their rewrites have bugs, and they would like for someone to fix said bugs for free, there is absolutely no one who will feel obligated to help them out.
> Because it takes a massive amount of developer work
You know what else takes "a massive amount of developer work"?
"any LLM-generated code must be reviewed by a good programmer"
And this is the crux of the matter with using LLMs to generate code for everything but really simple greenfield projects: They don't really speed things up, because everything they produce HAS TO be verified by someone, and that someone HAS TO have the necessary skill to write such code themselves.
LLMs save time on the typing part of programming. Incidentially that part is the least time consuming.
The submitter is supposed to be the good programmer; if not, then maintainers may or may not review it themselves depending on the importance of the feature.
And yes of course they need to be able to write the code themselves, but that's the easy part: any good developer could write a full production OS by themselves given access to documentation and literature and an enormous amount of time. The problem is the time.
> The submitter is supposed to be the good programmer;
And how will that be assured? Everyone can open a PR or submit a bug.
> The problem is the time.
But not the time spent TYPING.
The problem is the time spent THINKING. And that's a task that LLMs, which are nothing other than statistical models trying to guess the next token, really aren't good at.
There are only 4 successful general purpose production OSes (GNU/Linux, Android/Linux, Windows, OS X/iOS) and only one of those made by the open source community (GNU/Linux).
And a new OS needs to be significantly better than those to overcome the switching costs.
> There are only 4 successful general purpose production OSes
Feel like you are using a very narrow definition of "success" here. Is BSD not successful? It is deployed on 10s of millions of routers/firewalls/etc in addition to being the ancestor of both modern MacOS and PlaystationOS...
What about IBM i and z/OS, and Stratus VOS, and Burroughs MCP, and Tandem GUARDIAN, and VxWorks and OS-9 and… These all not only still exist but run huge transaction volume (for the mainframe and minicomputer systems) and run a huge amount of embedded systems (for the embedded OSes).
> And a new OS needs to be significantly better than those to overcome the switching costs.
Who cares if nobody switches to it as their daily driver? The goal you proposed was "viable", not "widely used". The former is perfectly possible without LLMs (as history has proved), and the latter is unrelated to how you choose to make the OS.
Just because they have been made before LLMs doesn't mean it can be done again, since there was just one success (GNU/Linux) and that success makes it much harder for new OSes since they need to better then it
The sad part is, how infinitely more functional these simple, static HTML documents are, compared to much of the shit that floods the "modern" web.
Ofc these pages cannot replace SPAs. That's not the point. The point is: Much of the web isn't SPAs. And much of what is SPAs shouldn't be SPAs. Much of the web is displaying static, or semi-static information. Hell, much of the web is still text.
But somehow, the world accepted that displaying 4KB of text somehow has to require transmitting 32MiB of data, much of it arbitrary code that has no earthly business eating my CPU cycles, as the new normal. Somehow everyone accepts that text-only informational pages need to abuse the scroll-event, or display giant hero-banners. Somehow, having a chatbot-popup on a restaurants menu-page is a must (because ofc I wanna talk to some fuckin LLM wrapper about the fries they sell!!!), but a goddamn page denoting the places address and telephone number is nowhere to be found.
Everyone did accept that because when you needed information from a page that pulls that shit, you don't have a choice, and when you did have a choice, all the others did it too.
Nowadays people just ask ChatGPT for the information they need so they don't have to visit those awful sites anymore.
Some of the stuff we have been adding since then is GOOD though.
Some examples:
We now have to accommodate all types of user agents, and we do that very well.
We now have complex navigation menus that cannot be accessible without JavaScript, and we do that very well.
Our image elements can now have lots of attributes that add a bit of weight but improve the experience a lot.
Etc.
Also, things are improving/self-correcting. I saw a listing the other day for senior dev with really good knowledge of the vanilla stuff. The company wants to cut down on the use of their FE framework of choice.
I cannot remember seeing listings like that in 2020 or 2021.
PS.
I did not mean this reply as a counterpoint.
What I meant to say is, even if we leave aside the SPAs that should not be SPAs, we see the problem in simple document pages too. We have been adding lots of stuff there too. Some is good but some is bad.
> We now have to accommodate all types of user agents, and we do that very well.
Simple websites don't even care about the UA.
> We now have complex navigation menus that cannot be accessible without JavaScript, and we do that very well.
Is there an actual menu which is more than a tree? Because a dir element that gets rendered by the UA into native menu controls would be just so much better.
Websites do care about the UA. They don’t care, at least most don’t care, about the User-Agent string. That is different.
About an element that gets rendered into native menu controls, I am not sure. I haven’t been following closely for the last two or three years. But that seems like a good candidate for a native element. 9 out 10 websites need it.
Not exactly the best conditions for making good and measured choices, I'd prefer if we didn't add more urgency than what most of us (Europeans) feel already. Everyone already have it on their mind when making purchasing decisions now, no need to also make those people do rash decisions.
The reason Europeans feel the urgency is because of rigid minders and failure to act at least 10-15 years ago. So now it’s ok to bite the bullet a bit. It’s a lesson for the next time.
Why does my text-editor need to do "encryption at rest"? If I want data encrypted, I store it in an encrypted drive with a transparent en/decryption layer.
That is completely valid for personal threat models, I rely on LUKS/BitLocker for my daily driver too.
The specific gap this fills is 'Defense in Depth' + compliance. OS-level encryption (like FDE) is transparent once you log in. If you walk away from an unlocked machine, FDE does nothing.
App-level encryption, however, ensures the specific sensitive notes remain encrypted on disk even while the OS is running and the user is authenticated.
It's also portable as it allows the encrypted blob to be moved across untrusted transports (email, USB, cloud) without needing to set up an encrypted container/volume on the destination.
For FIPS/NIST workflows, relying solely on the OS often isn't enough for the auditor; having the application control the keys explicitly satisfies the 'data protection' control regardless of the underlying storage medium.
...then I might as well ask what happens when I walk away from the encrypting edior while a file is still open. User Error can happen with any encryption or security schema. Pointing out a trueism is not an argument.
> It's also portable
So is encrypting files using a specialized tool. I don't need my editor to do this. The entire point of my criticism, and indeed the entire point of this thread, is that software that should focus on a narrow task, tries to do way too much, leading to problems.
For what it's worth I understood the argument and think it is valid. It's one thing for the file you're working on to be vulnerable if you walk away leaving the editor open; it's another for all of your other files to be vulnerable too. It's O(1) vs. O(n). The difference is clearly not zero.
As funny as the "Bush hid the facts" bug may be, there is a world of difference between an embarassing mistake by a function that guesses the text encoding wrong, and a goddamn remote code execution with an 8.8 score
> and we have other battles we fight.
Except no, we don't. notepad.exe was DONE SOFTWARE. It was feature complete. It didn't have to change. This is not a battle that needed fighting, this was hitting a brick wall with ones fist for no good reason, and then complaining about the resulting pain.
They likely knew nobody would be drawn to WordPad by the additions, so they had to scavenge their rapidly diminishing list of actually useful software for sacrifices on the altar to their outrageous AI investments.
How long were they threatening to kill snipping tool despite it being a perfectly serviceable piece of kit so we could switch to some shitty alternative?
They did ultimately kill it though - and then they re-created it as a bloated UWP version that is an insane 449 MEGABYTES in size! The old win32 Snipping Tool used to be only a few kilobytes...
For a good built in "done" text editor, theres apples textedit. It's barely changed since NeXTSTEP and works flawlessly and is FOSS. As much as I hate apple there's a reason I have GNUstep installed on most of my *nix boxes
This definition in the first paragraph on Wikipedia matches my understanding of it as a security consultant:
> The ability to trigger arbitrary code execution over a network (especially via a wide-area network such as the Internet) is often referred to as remote code execution (RCE or RCX). --https://en.wikipedia.org/wiki/Arbitrary_code_execution
Issues in handling local files, whether they require user interaction or not, are just that
Doesn't take away from the absurdity that notepad isn't a notepad but does extensive file contents parsing
> Except no, we don't. notepad.exe was DONE SOFTWARE
While 8.8 score is embarrassing, by no measure notepad was done software. It couldn't load a large text file for one, its search was barely functional, had funky issues with encoding, etc.
Notepad++ is closer to what should be expected from an OS basic text editor
What counts as "large"? I'm pretty sure at some point in my life I'd opened the entirety of Moby Dick in Notepad. Unless you want to look for text in a binary file (which Notepad definitely isn't for) I doubt you'll run into that problem too often.
Also, I hope the irony of you citing Notepad++ [1] as what Notepad should aim to be isn't lost on you. My point being, these kinds of vulnerabilities shouldn't exist in a fucking text editor.
Remote into a machine that you're not allowed to copy data out of. You only have the utilities baked into Windows and whatever the validated CI/CD process put there. You need to open a log file that has ballooned to at least several hundred megabytes, maybe more.
Moby Dick is about 1MB of text. That's really not much compared to a lot of log files on pretty hot servers.
I do agree though, if we're going to be complaining about how a text editor could have security issues and pointing to Notepad++ as an example otherwise, its had its own share of notable vulnerabilities even before this update hijacking. CVE-2017-8803 had a code execution vulnerability on just opening a malicious file, this at least requires you to click the rendered link in a markdown file.
Oh right, generated files exist. Though logging systems usually have a rollover file size you can configure, should this happen to you in real life.
Honestly I'm okay with having to resort to power tools for these edge cases. Notepad is more for the average user who is less likely to run into 100 MB text files and more likely to run into a 2 kB text file someone shared on Discord.
> Notepad is more for the average user who is less likely to run into 100 MB text files and more likely to run into a 2 kB text file someone shared on Discord.
There's no reason it shouldn't handle both use cases.
> Though logging systems usually have a rollover file size you can configure, should this happen to you in real life
I get what you're saying. But if things were done right I probably wouldn't have to be remoting into this box to hunt for a log file that wasn't properly being shipped to some other centralized logging platform.
I know about the vulnerabilities in notepad++, however I was referring to the feature set.
Regarding large, I am referring to log files for example. I think the issue was lack of use of memory mapped files, which meant the entire file was loaded to RAM always, often giving the frozen window experience
Plus for many years Word was one of the main cash cows for MS, so they didn't want to make an editor that would take away from Word.
And you could see how adding new things adds vulnerabilities. In this case they added ability to see/render markdown and with markdown they render links, which in this case allowed executing remote code when user clicks on a link.
> Absolutely false. I have built tons of tools which are feature complete and continue to work to this day without intervention
And how many of these tools are mission critical to the point that they are installed on almost every Linux box in existence, probably invoked tens of billions of times per day, both by humans and software, and the entire world would be in deep goddamn trouble if there was a serious security flaw that doesn't get fixed immediately?
You’ve moved the goalposts so far away, they’ve left the breathable atmosphere. Look at your condition, it’s over 50 words. I didn’t say “all software can be done”, I just said that it’s not true that software is never done. It’s not a universal truth that applies to all software.
Consumer hardware will always be a market worth serving for companies who don't see their stock price as their product.
If the existing companies are unwilling to make a sale, I am sure new players will arise picking up their slack.
https://www.youtube.com/watch?v=SrX0jPAdSxU
reply