And get rid of zero-delimited strings in all APIs. Horribly dangerous.
bash is not all that great a scripting language. We have many better options to choose from. Demote it from its position at the heart of everything put.. oh, maybe Python 3 in its place.
VFS... it's useful to have the notion of a volume root for backups and mirroring and mounting and such. I'll give Windows this, except I'd prefer volume names to drive letters. Like old school DEC stuff.
Trash/recycle implemented at system level. Automatic deleting of the oldest trashed files when disk space is needed.
I'd also like to see all configuration done via sqlite. Use a sqlite editor instead of a text editor. It'll be easier to search and to figure things out. XML would be my second choice.
Better handling of thrash conditions and working sets, so the system will be more responsive. It's irritating when you get no prompt feedback to acknowledge your user action and you're wondering if the key stuck or if you mis-typed, or you forget what you typed because it isn't on the screen yet. Things that take a while should be low priority background threads. But acknowledging user keypresses and clicks should be more like a software interrupt, and the required code only swapped out in extreme situations. (Sorry, but mlock is too simplistic.)
Acknowledge to the user that an app is being loaded.... before the window comes up. Plus an option to cancel the load if you change your mind.
A/tmp file system that is never written to disk at all unless necessary. Kind of a cache in reverse.
Set user and group on folders instead of files, so you can more easily be assured of what has access to what based on path spec?
Just examples of what I think might work. Maybe a thread to brainstorm this?
Got mixed feelings about this. There's a real security risk that this would help a lot with. But... user desires and code bloat always expand to take all available resources. So, there is a downside.
What if the executable itself is compromised? Really, we need a coherent philosophy re digital signing. Do we cede control to the owners of the certificates, or to hackers? I say neither. If the signature is broken, always inform the user and always let the user make a command decision.
If the owner of a host signs his own executables, that's fine - if he builds them himself from source. Make sure we allow this on all binaries. Don't mandate a particular signing authority. But then we must inform always inform the user at runtime just who signed what he's about to load. Because hackers can sign, too.
One objection I have is they're not well suited to binary data. This content-encoding stuff seems klugey and inefficient. But that's not a deal breaker.
Deep linking and embedding is what makes all sorts of problems possible. Cross site scripting, linked images that bog down page loads, tracker pixels and dead links.
Suppose cross site embedding and scripting were disallowed? Just don't support them in the browser - or at least not without a click to bring up an image. The infrastructure for ads would have to be overhauled, yes. A price worth paying.
Suppose there were restrictions on deep linking, so that a site could explicitly state what is or isn't exported? That way a Web developer could overhaul his logic any time without fear of breaking other sites' links into his site. I can't endorse making Referer mandatory, so a custom browser can bypass this easily, but... that's the user's responsibility.
Yes, I'm talking about limiting options. Options to do things that we've all established were bad ideas. That's why we have laws. Some laws, anyway. And RFCs. And call gates and page protection and user permissions. Make it harder to shoot yourself or someone else in the foot, and we can have (reasonable) freedom without (needless) fear. Seek the best balance by considering things on a case-by-case basis,
Maximum sustainable freedom by means of rules that make sense.
Projects go all bloat plus legacy, until it seems a project only exists for its own sake. I see only one solution: move on. Maybe split the difference by forking the code and then innovating and jettisoning cruft, or maybe start from scratch. But one way or the other, move on.
I can foresee a day when Unix style operating systems will be obsolete, when that whole paradigm will be replaced by something better. It won't happen without wailing and gnashing of teeth.
I'm not a systemd fan, Bad implementation from an arrogant culture. But let's try again, huh? And let's start from a basis of user needs and best practices this time.
Free exchange or censorship. Pick one. And besides, censorship never fixed the problem of fake news. The only solution to fake news is for readers not to be gullible.
Want a second opinion? Here's one: HTTP and HTML are getting long in the tooth, and Javascript is bloat. Maybe it's time to come up with a new stack? Something with better controls for deep linking and embedding, and better support for distributed/cached store-and-forward, and mechanisms so Web 2.0 doesn't have to be such a bolt-on kluge. Maybe a decentralized reputation system so we can choose our own echo chambers more readily.
I'm disappointed that after all these years Tim speaks mainly in slogans and generalities, and still can't avoid contradicting himself. Let's show him how it's done by talking brass tacks.
I could harsh on PHP until the cows come home, but that would be annoying. So I'll just say that this sort of security problem shows that it's impractical to write anything secure in PHP. Why? Mainly because it adds a layer of complexity atop compiled binary, and it adds source code access once a hacker has got past a certain level, and... oh, it's just all kinds of insecure.
Just why did PHP become so popular, anyway? I really don't see the attraction. Now WordPress would be a wonderful thing, if only they'd ditch the PHP. It would be a little harder to customize and extend, but far from impossible. Worst case, we could supply a scripting language ONLY for custom extensions. Basically a macro language. Python's embeddable.
(No, I don't consider a widely used API to be a custom extension. That's part of the core.)
More opinion: in a production system, scripting languages and macros should be only for custom extensions, and never for core code. There should never be scripts BEHIND an API. If WordPress were written in a compiled language and run as a binary, it would be less easy to hack. But not C. Those damn pointer arithmetic exploits...
Firefox is kind of dying for a lot of reasons. Why not use it as a guinea pig?
This can be a great reality check for Rust. Find and fix the flaws in the language by trying to use it for something real and something big. There's a chance that a better language and a better browser will both emerge from this in parallel.
The problems would get spotted and fixed very fast. But the real mischief is when they break so subtly you don't realize it until many years too late. This is what C is prone to, because of those horrid pointers. This is why C sucks.
Unchecked pointers are bad, mmmkay? Don't make excuses for a bad tool. A good workman chooses a better tool. Unless he's prevented from doing so by apologists for bad tools.
And the gaslighting only adds insult to injury. Seriously. Fuck that whole way of thinking. A bad manager chooses bad tools, and then blames the coders. Life is too short for that shit.
The one virtue of assembly is that only the bare minimum is written in assembly nowadays. That minimizes the risk. I once had a boss wanted a whole suite of apps written in assembly because it would run faster. He would not listen to common sense. What an asshole. Went out of business after I quit. I don't miss him.
Now his spiritual heirs are telling us to write the whole damn suite of apps in C/C++. And the apps are bigger these days.
He derives no sense of meaning or purpose from his work. It rather depresses him. But hey, it's a living. And he'll never, ever get laid off and forced to train some guy from Bangalore.
I have a feeling if we ever get rid of the stupid managers, the ones they're replaced with will have us avoid using C, and restrict to a subset of C++. Because an intelligent manager understands risk management.
If you do it wrong in C - or assembly- it's really, disastrously wrong. And it's wrong in a way you don't realize until years too late.
But really, that's a defect in C. And in humans, that we're not all capable of coding flawlessly. Which side of the problem is easier to fix? Oh... false dichotomy. Perverse human nature prevents us from addressing the issue with our tools!
It's a poor workman who chooses bad tools. Or a PHB who chooses for him.
C was a great innovation for its day, but it has lasted far longer than it had any business lasting. Likewise Perl. Likewise SQL. Language design is mostly churn and not enough progress. They're not working the problems. That denies us something good to move on to.
Safe pointers, smart pointers, ditching the preprocessor - if I'd had oodles of free time I'd have done everything Rust attempts years ago. It seemed self evident to me that long ago, but the people who actually have the free time waste that free time inventing stuff like PHP.
Or maybe PHP and the like are just easier to invent. It does seem that not all that much effort was put in.
C is responsible for the vast majority of stray pointer and buffer overrun vulnerabilities. Together with SQL injection and macros, it's making computing unsafe. C++ ameliorates the problem but does not eliminate it.
C/C++ are low-level languages used to implement everything else. There is no direct replacement. We desperately need one. What's the holdup, folks?
I had a look at Rust and could only ask: why isn't this twenty years further along by now? Oh, and... what's with that huge embedded runtime?
The trouble is, the system rewards the incompetent. The skills needed to do a good job are not at all the same skills that are needed to get and keep a good job. Just look at Congress. Most of those clowns have been there for years.
I'll shut up and learn from anyone with a proven track record of technical success. I won't trust anyone with a lengthy, proven track record of failure. I'm very much in the minority that way.
The entire software development industry is rife with this sort of thing. Why? Because we're not doing what it takes to fix the problem.
If you just up and leave, all you've earned is a reprieve. You'll run into it all over again somewhere else. You need to punish the gaslighters and their enablers, or else nothing will change.
First, document everything. Every damn thing. Be prepared to prove things to any available objective third party you might happen across. Then, get a lawyer. Then, and only then... line up your next job.
Use your documentation to cause as much pain and embarrassment as possible as you go out the door. Burn the place down. Cause them legal problems if you can. Mess with their politics. Learn who hates whom and turn them against each other. Cause the worst offenders to lose face. If it's publicly traded, cause investor relations problems.
You owe it to the world to destroy these bastards. No mercy.
Slashdot Mirror
Here's the problem. Hard real time embedded code needs to run fast IN TEST MODE.
No, I'm not anti valgrind. I'm just saying it's doesn't fix everything.
Or maybe... cysts.
What's the case for trusting big anything else?
The less data we put out there, the less they can steal. That, and proxies.
When I was a little kid I left my bike out and it got stolen. So I never did that again. That strategy worked.
And get rid of zero-delimited strings in all APIs. Horribly dangerous.
/tmp file system that is never written to disk at all unless necessary. Kind of a cache in reverse.
bash is not all that great a scripting language. We have many better options to choose from. Demote it from its position at the heart of everything put.. oh, maybe Python 3 in its place.
VFS... it's useful to have the notion of a volume root for backups and mirroring and mounting and such. I'll give Windows this, except I'd prefer volume names to drive letters. Like old school DEC stuff.
Trash/recycle implemented at system level. Automatic deleting of the oldest trashed files when disk space is needed.
I'd also like to see all configuration done via sqlite. Use a sqlite editor instead of a text editor. It'll be easier to search and to figure things out. XML would be my second choice.
Better handling of thrash conditions and working sets, so the system will be more responsive. It's irritating when you get no prompt feedback to acknowledge your user action and you're wondering if the key stuck or if you mis-typed, or you forget what you typed because it isn't on the screen yet. Things that take a while should be low priority background threads. But acknowledging user keypresses and clicks should be more like a software interrupt, and the required code only swapped out in extreme situations. (Sorry, but mlock is too simplistic.)
Acknowledge to the user that an app is being loaded.... before the window comes up. Plus an option to cancel the load if you change your mind.
A
Set user and group on folders instead of files, so you can more easily be assured of what has access to what based on path spec?
Just examples of what I think might work. Maybe a thread to brainstorm this?
Got mixed feelings about this. There's a real security risk that this would help a lot with. But... user desires and code bloat always expand to take all available resources. So, there is a downside.
What if the executable itself is compromised? Really, we need a coherent philosophy re digital signing. Do we cede control to the owners of the certificates, or to hackers? I say neither. If the signature is broken, always inform the user and always let the user make a command decision.
If the owner of a host signs his own executables, that's fine - if he builds them himself from source. Make sure we allow this on all binaries. Don't mandate a particular signing authority. But then we must inform always inform the user at runtime just who signed what he's about to load. Because hackers can sign, too.
Informed consent, and the user beware.
One objection I have is they're not well suited to binary data. This content-encoding stuff seems klugey and inefficient. But that's not a deal breaker.
Deep linking and embedding is what makes all sorts of problems possible. Cross site scripting, linked images that bog down page loads, tracker pixels and dead links.
Suppose cross site embedding and scripting were disallowed? Just don't support them in the browser - or at least not without a click to bring up an image. The infrastructure for ads would have to be overhauled, yes. A price worth paying.
Suppose there were restrictions on deep linking, so that a site could explicitly state what is or isn't exported? That way a Web developer could overhaul his logic any time without fear of breaking other sites' links into his site. I can't endorse making Referer mandatory, so a custom browser can bypass this easily, but... that's the user's responsibility.
Yes, I'm talking about limiting options. Options to do things that we've all established were bad ideas. That's why we have laws. Some laws, anyway. And RFCs. And call gates and page protection and user permissions. Make it harder to shoot yourself or someone else in the foot, and we can have (reasonable) freedom without (needless) fear. Seek the best balance by considering things on a case-by-case basis,
Maximum sustainable freedom by means of rules that make sense.
Projects go all bloat plus legacy, until it seems a project only exists for its own sake. I see only one solution: move on. Maybe split the difference by forking the code and then innovating and jettisoning cruft, or maybe start from scratch. But one way or the other, move on.
I can foresee a day when Unix style operating systems will be obsolete, when that whole paradigm will be replaced by something better. It won't happen without wailing and gnashing of teeth.
I'm not a systemd fan, Bad implementation from an arrogant culture. But let's try again, huh? And let's start from a basis of user needs and best practices this time.
Much more worth talking about.
https://solid.mit.edu/
Free exchange or censorship. Pick one. And besides, censorship never fixed the problem of fake news. The only solution to fake news is for readers not to be gullible.
Want a second opinion? Here's one: HTTP and HTML are getting long in the tooth, and Javascript is bloat. Maybe it's time to come up with a new stack? Something with better controls for deep linking and embedding, and better support for distributed/cached store-and-forward, and mechanisms so Web 2.0 doesn't have to be such a bolt-on kluge. Maybe a decentralized reputation system so we can choose our own echo chambers more readily.
I'm disappointed that after all these years Tim speaks mainly in slogans and generalities, and still can't avoid contradicting himself. Let's show him how it's done by talking brass tacks.
Couldn't resist.
I tried WordPress for a while, and I tried some PHP coding. I'm a tad bitter.
I could harsh on PHP until the cows come home, but that would be annoying. So I'll just say that this sort of security problem shows that it's impractical to write anything secure in PHP. Why? Mainly because it adds a layer of complexity atop compiled binary, and it adds source code access once a hacker has got past a certain level, and... oh, it's just all kinds of insecure.
Just why did PHP become so popular, anyway? I really don't see the attraction. Now WordPress would be a wonderful thing, if only they'd ditch the PHP. It would be a little harder to customize and extend, but far from impossible. Worst case, we could supply a scripting language ONLY for custom extensions. Basically a macro language. Python's embeddable.
(No, I don't consider a widely used API to be a custom extension. That's part of the core.)
More opinion: in a production system, scripting languages and macros should be only for custom extensions, and never for core code. There should never be scripts BEHIND an API. If WordPress were written in a compiled language and run as a binary, it would be less easy to hack. But not C. Those damn pointer arithmetic exploits...
Firefox is kind of dying for a lot of reasons. Why not use it as a guinea pig?
This can be a great reality check for Rust. Find and fix the flaws in the language by trying to use it for something real and something big. There's a chance that a better language and a better browser will both emerge from this in parallel.
The problems would get spotted and fixed very fast. But the real mischief is when they break so subtly you don't realize it until many years too late. This is what C is prone to, because of those horrid pointers. This is why C sucks.
Unchecked pointers are bad, mmmkay? Don't make excuses for a bad tool. A good workman chooses a better tool. Unless he's prevented from doing so by apologists for bad tools.
And the gaslighting only adds insult to injury. Seriously. Fuck that whole way of thinking. A bad manager chooses bad tools, and then blames the coders. Life is too short for that shit.
The one virtue of assembly is that only the bare minimum is written in assembly nowadays. That minimizes the risk. I once had a boss wanted a whole suite of apps written in assembly because it would run faster. He would not listen to common sense. What an asshole. Went out of business after I quit. I don't miss him.
Now his spiritual heirs are telling us to write the whole damn suite of apps in C/C++. And the apps are bigger these days.
Operator overloading and templates obfuscate and much as that damn preprocessor.
Maybe templates are worth it. They bring significant added value. But they do make code hard to follow sometimes.
Multiple inheritance is a nightmare.
He derives no sense of meaning or purpose from his work. It rather depresses him. But hey, it's a living. And he'll never, ever get laid off and forced to train some guy from Bangalore.
Now... how do we fix the managers?
I have a feeling if we ever get rid of the stupid managers, the ones they're replaced with will have us avoid using C, and restrict to a subset of C++. Because an intelligent manager understands risk management.
If you do it wrong in C - or assembly- it's really, disastrously wrong. And it's wrong in a way you don't realize until years too late.
But really, that's a defect in C. And in humans, that we're not all capable of coding flawlessly. Which side of the problem is easier to fix? Oh... false dichotomy. Perverse human nature prevents us from addressing the issue with our tools!
It's a poor workman who chooses bad tools. Or a PHB who chooses for him.
C was a great innovation for its day, but it has lasted far longer than it had any business lasting. Likewise Perl. Likewise SQL. Language design is mostly churn and not enough progress. They're not working the problems. That denies us something good to move on to.
Safe pointers, smart pointers, ditching the preprocessor - if I'd had oodles of free time I'd have done everything Rust attempts years ago. It seemed self evident to me that long ago, but the people who actually have the free time waste that free time inventing stuff like PHP.
Or maybe PHP and the like are just easier to invent. It does seem that not all that much effort was put in.
in ways that don't really address the deficiencies of C very well.
Oh, and it's got lots of new bad ideas.
All we have to do then is fix the coders and all our problems will be solved!
Wait. How do we fix the coders?
It's a poor manager who blames his coders.
C is responsible for the vast majority of stray pointer and buffer overrun vulnerabilities. Together with SQL injection and macros, it's making computing unsafe. C++ ameliorates the problem but does not eliminate it.
C/C++ are low-level languages used to implement everything else. There is no direct replacement. We desperately need one. What's the holdup, folks?
I had a look at Rust and could only ask: why isn't this twenty years further along by now? Oh, and... what's with that huge embedded runtime?
The trouble is, the system rewards the incompetent. The skills needed to do a good job are not at all the same skills that are needed to get and keep a good job. Just look at Congress. Most of those clowns have been there for years.
I'll shut up and learn from anyone with a proven track record of technical success. I won't trust anyone with a lengthy, proven track record of failure. I'm very much in the minority that way.
The entire software development industry is rife with this sort of thing. Why? Because we're not doing what it takes to fix the problem.
If you just up and leave, all you've earned is a reprieve. You'll run into it all over again somewhere else. You need to punish the gaslighters and their enablers, or else nothing will change.
First, document everything. Every damn thing. Be prepared to prove things to any available objective third party you might happen across. Then, get a lawyer. Then, and only then... line up your next job.
Use your documentation to cause as much pain and embarrassment as possible as you go out the door. Burn the place down. Cause them legal problems if you can. Mess with their politics. Learn who hates whom and turn them against each other. Cause the worst offenders to lose face. If it's publicly traded, cause investor relations problems.
You owe it to the world to destroy these bastards. No mercy.
Spezgate?
The next employer was also a sleazeball.
If the landing struts are subject to a compressive force, you've probably landed. If not, you haven't. Why wouldn't the computer make use of this?
Am I missing something, or is this a stupid design?