PaX
joined 2 years ago
If you like Unixy editors, highly recommend also looking into acme
Russ Cox describes it in this video as more like an "integrating development environment" as in it works with your surrounding operating system rather than an "integrated development environment"
Doesn't shine as much on Unix as in Plan 9 though. Also no linter or formatter built into or distributed with acme but you probably could get your language's usual tools to work pretty well with it
Ed is the standard text editor.
Plan 9 posting
2
Die shot of the MIPS R10000 microprocessor, fabricated by NEC as the NEC VR10000 (with a story!)
(hexbear.net)
cross-posted from: https://hexbear.net/post/1747735
CPU-posting on main
MTI = MIPS Technologies (company that made MIPS (Microprocessor without Interlocked Pipeline Stages) processors, they make RISC-V processors now lmao)
At the time when the MIPS R10000, known as the "T5" while in development, was being designed, MTI had made a name for themselves as designers of high-performance computer microprocessors along the lines of the then-new philosophy of reduced instruction set computing (RISC). Actually, their R2000 design was the first commercially-available RISC microprocessor. By the time the T5 was being designed, they were no longer alone in the RISC microprocessor market. Several companies, including IBM and Motorola (joined together in the AIM alliance which produced PowerPC), DEC (who designed the Alpha line of RISC microprocessors after MTI owned them in the 80s when their radically simpler chips were performing better than VAXen), and Sun Microsystems (who were making the SPARC line of microprocessors) were now marketing RISC microprocessors. Not just even marketing but beating MTI in the market they had created. After trying and failing to develop their own complete computer systems alongside their chips, they were having financial difficulties until Silicon Graphics acquired MTI to secure availability of MIPS microprocessors for their famous ("it's a Unix system, I know this!") MIPS-based workstations and servers. Although their new (in 1993) R4000 and R4400 designs performed well compared to their contemporaries, they were quickly being made obsolete by MTI's competitor's new offerings and they were left with a problem:
The MIPS R4000 and the R4400, which is essentially an R4000 with bigger on-die caches, were more or less just an architectural evolution from the R2000. The R4000 made its performance in much the same way as the R2000 did, the classic RISC design process mantra: "let's make it simpler" and thus be able to run it faster. In particular, what this means for the R4000, and what is a key difference from its predecessors and its contemporaries, is a technique called superpipelining. In an instruction pipeline, the maximum speed at which your processor can issue instructions is set by the pipeline stage which takes the longest to complete. Superpipelining is one way of addressing this problem: you can subdivide each pipeline stage into 2 simpler pipeline stages that individually complete faster and thus be able to clock your chip faster without problems. However, this has its limits. Eventually, it becomes impossible to further "deepen" the pipeline like this or clock the processor faster in general without other problems. This is why MTI's competitors opted for the analogous superscalar approach: you can duplicate functional units of your processor and have multiple instructions "in flight" at the same time and usually this also involves multiple pipelines. At the time MTI thought this approach would result in more consistently higher performance (not to mention save die space) but were quickly proven wrong when their competitor's superscalar (and often with other architectural tricks) chips were outperforming the R4000 in spite of MTI's fabrication partners constantly improving their process and releasing chips that ran at higher and higher speeds.
Enter the MIPS R8000 (die not pictured here) in 1994, a weird and expensive 6-chip 4-way superscalar design meant for the high-end microprocessor market while the next-generation T5 (which would become the MIPS R10000, as mentioned earlier) was under development. It didn't sell well because of its high price and the fact that its integer performance, important for general-purpose computing applications, was lacking compared to the 200-MHz R4400 that was being sold by then. It did, however, have impressive floating-point performance, which landed many R8000-based systems in the TOP500 supercomputer list for a time. But this design could never be the high-performance and general-purpose processor MTI needed to compete with their competitor's offerings...
Introduced in 1996, the MIPS R10000 (die IS pictured here) was a significant departure from the architecture of the R4000 (which more or less was directly derived from the first research done at Stanford University where MIPS was initially created over a decade earlier). Dropping the superpipeline approach, the R10000 is a 4-way superscalar processor even capable of executing instructions out of order! Another big change is that it has a branch predictor and speculatively executes instructions after a branch as opposed to the R4000, which used the classic MIPS "branch delay slot" technique to schedule one more instruction in the pipeline after a branch and then stall lol (they should have added even more delay slots, caring about binary compatibility is liberalism). It's hard to find benchmarks for something this old but this design performed at least several times faster than an R4400 at about the same clock speed!
If you like my CPU posting and want me to post more in the future let me know
Also ask me any questions if you want too and I'll try to answer
I'll believe it when we dismantle the nukes, class society, and fossil fuel industry. A better world is possible but only if we fight for it.
Programmers can trust language security features too much...
Of course, they're nice to have and really can make things easier to implement securely but it's still very easy to introduce security problems or bugs into any code. This is just an unsolvable problem of writing imperative code. All imperative code will reliably have memory leaks (even in Java!) and security holes because no compiler can check to see if you thought of everything.
And large and complex compilers/interpreters with these security features can end up introducing their own security problems or bugs in the process of implementing them.
I'm just tired of people entirely dismissing languages like C because they don't have these features. Especially when the operating systems their code runs on and their languages may even be implemented in C!
C is very reliable. It works almost everywhere with very little resources or overhead and many of the most fundamental parts of our systems (that have to work reliably) are written in C. Many of the languages in that image are even implemented in C.
If you want to write portable, fast, and simple code C can help you with that if you use it in the right way.
This has always felt untrue to me. The command line has always been simple parts. However we cannot argue that this applies to all Unix-like systems: The monolithic Linux kernel, Kerberos, httpd, SAMBA, X windowing, heck even OpenSSL. There's many examples of tooling built on top of Unix systems that don't follow that philosophy.
I can see why you would come to think that if all you've been exposed to is Linux and its orbiting ecosystem. I agree with you that modern Unix has failed to live up to its ideals. Even its creators began to see its limitations in the late 80s and began to develop a whole new system from scratch.
Depends on what you mean. "Everything is a file"? Sure, that metaphor can be put to rest.
That was never true in the first place. Very few things under Unix are actually represented as files (though credit to Linux for pursuing this idea in kernel-space more than most). But Plan 9 shows us this metaphor is worth expanding and exploring in how it can accomplish being a reliable, performant distributed operating system with a fraction of the code required by other systems.
Kubernetes is more complex than a single Unix system. It is less complex than manually configuring multiple systems to give the same benefits of Kubernetes in terms of automatic reconciliation, failure recovery, and declarative configuration. This is because those three are first class citizens in Kubernetes, whereas they're just afterthoughts in traditional systems. This also makes Kubernetes much more maintainable and secure. Every workload is containerized, every workload has predeclared conditions under which it should run. If it drifts out of those parameters Kubernetes automatically corrects that (when it comes to reconciliation) and/or blocks the undesirable behaviour (security). And Kubernetes keeps an audit trail for its actions, something that again in Unix land is an optional feature.
My point is Kubernetes is a hack (a useful hack!) to synchronize multiple separate, different systems in certain ways. It cannot provide anything close to something like a single system image and it can't bridge the discrete model of computation that Unix assumes.
This also makes Kubernetes much more maintainable and secure. Every workload is containerized, every workload has predeclared conditions under which it should run. If it drifts out of those parameters Kubernetes automatically corrects that (when it comes to reconciliation) and/or blocks the undesirable behaviour (security). And Kubernetes keeps an audit trail for its actions, something that again in Unix land is an optional feature.
All these features require a lot of code and complexity to maintain (latest info I can find is almost 2 million as of 2018). Ideally, Kubernetes is capable of what you said, in the same way that ideally programs can't violate Unix filesystem DAC or other user permissions but in practice every line of code is another opportunity for something to go wrong...
Just because something has more security features doesn't mean it's actually secure. Or that it's maintainable without a company with thousands of engineers and tons of money maintaining for you. Keeping you in a dependent relationship.
It also has negligible adoption compared to HTTP. And unless it provides an order of magnitude advantage over HTTP, then it's going to be unlikely that developers will use it. Consider git vs mercurial. Is the latter better than git? Almost certainly. Is it 10x better? No, and that's why it finds it hard to gain traction against git.
So? I don't expect many of these ideas will be adopted in the mainstream under the monopoly-capitalist market system. It's way more profitable to keep selling support to manage sprawling and complex systems that require armies of software engineers to upkeep. I think if state investment or public research in general becomes relevant again maybe these ideas will be investigated and adopted for their technical merit.
Even an online filesystem does not guarantee high availability. If I want highly available data I still need to have replication, leader election, load balancing, failure detection, traffic routing, and geographic distribution. You don't do those in the filesystem layer, you do them in the application layer.
"Highly available" is carrying a lot of weight there lol. If we can move some of these qualities into a filesystem layer (which is a userspace application on some systems) and get these benefits for free for all data, why shouldn't we? The filesystem layer and application layer are not 2 fundamentally separate unrelated parts of a whole.
Nice ad hominem. I guess it's rules for thee, but not for me.
Lol, stop being condescending and I won't respond in kind.
So what's the problem? Didn't you just say that the Unix way of doing things is outdated?
I think the reason the Unix way of doing things is outdated is cuz it didn't go far enough!
Dismissal based on flawed anecdote is preconception.
What? lol
It's not a flawed anecdote or a preconception. They had their own personal experience with a cloud tool and didn't like it.
You can't  someone into liking something.
I'd rather hire an open-mined junior than a gray-bearded Unix wizard that dismisses anything unfamilar.
I'm not a gray-bearded Unix wizard and I'm not dismissing these tools because they're unfamiliar. I have technical criticism of them and their approach. I think the OP feels the same way.
The assumption among certain computer touchers is that you can't use Kubernetes or "cloud" tools and not come away loving them. So if someone doesn't like them they must not really understand them!
It's hard to not take that as bad faith.
They probably could've said it nicer. It's still no excuse to dismiss criticism because you didn't like the tone.
I think Kubernetes has its uses, for now. But it's still a fundamentally limited and harmful (because of its monopolistic maintainers/creators) way to do a kind of distributed computing. I don't think anyone is coming for you to take your Kubernetes though...
That's a great way of putting it, thanks. I'm actually only 30 years old (lol).
Yeahh, and I saw someone compare you to the "old man yelling at cloud" lol. Even though there are good reasons to yell at the cloud hehe
Sometimes I feel there's so few people who've ever used or written software at this level in the part of the industry I find myself in. It seems more common to throw money at Amazon, Microsoft, and more staff.
I've replaced big Java systems with small Go programs and rescued stalled projects trying to adopt Kubernetes. My fave was a failed attempt to adopt k8s for fault tolerance when all that was going on was an inability to code around TCP resets (concurrent programming helped here). That team wasn't "unskilled"; they were just normal people being crushed by complexity. I could help because they just weren't familiar with the kind of problem solving I was, nor what tooling is available without installing extra stuff and dependencies.
I haven't had the "privilege" of working for a wage in the industry (and I still don't know if I want to) but I think I know what you mean. I've seen this kind of tendency even in my friends who do work in it. There is less and less of a focus on a whole-system kind of understanding of this technology in favor of an increased division of labor to make workers more interchangeable. Capitalists don't want people with particular approaches capable of complex problem-solving and elegant solutions to problems; they want easily-replaceable code monkeys who can churn out products. Perhaps there is a parallel here with what happened to small-scale artisan producers of commodities in early capitalism as they were wiped out and absorbed into manufactories and forced to do ever-increasingly small and repetitive tasks as part of the manufacture of something they once produced from scratch to final product in a whole process. Especially concerning is the increasing use of AI by employed programmers. Well, usually their companies forcing them to use AI to try to automate their work.
And like you gave an example of, this has real bad effects on the quality of the product and the team that develops it. From the universities to the workplace, workers in this industry are educated in the virtues of object-oriented programming, encapsulation, tooling provided by the big tech monopolies, etc. All methods of trying to separate programmers from each other's work and the systems they work on as a whole and make them dependent on frameworks sold or open-sourced™ by tech monopolies at the expense of creative and free problem-solving.
Glad at least you were able to unstall some of the projects you've been involved in!
Thanks for your understanding :)
Glad we could share ideas :3
You and other people in the thread gave me a lot to think about. Hope this comment made some sense lol.
Yeahh, you have a good point lol. Bash and the GNU ecosystem have developed their own sprawling problems.
I'm glad I at least got closer to understanding your criticism than they did.
Don't let anyone tell you you're old or naive or "stuck in the past" for thinking these things! There is a real crisis in the operating systems world that your criticism is reflecting. It takes an army of software engineers and billions of dollars to keep this ecosystem and these systems going and they still struggle with reliability and security. The reason it's like this is an issue of economic organization.
We can't go back to the old way of doing things but we can't keep maintaining these fundamentally flawed systems either. You may find something inspiring in this brief presentation by Rob Pike: http://doc.cat-v.org/bell_labs/utah2000/
view more: next ›