A better timeline?

Windows UI design peaked with Windows 98 and Unix UI design peaked with IRIX imo

I am so tired haha

Okay but it was less , relatively to now

Ohh, I know, I was just making a joke cuz ed will print ? when it doesn’t recognize a command and many people will see that over and over if they can’t figure out how to exit lol

I also got lost in vi and ed when I first used them lol

Tbh if I’m just making quick edits to config files or whatever I use nano lmao

?

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.

I see. Our motherboards have different chipsets (I have an X570 in mine). It probably has nothing to do with my issue…

Hoping those kernel parameters fix it. I wish I could help further. PCs are just a bottomless, mostly undocumented rabbithole :(

What motherboard do you have? Also what happens exactly when the lock-ups happen? Have you ever been playing audio when the lock-ups happen and does it loop or stop or keep playing?

I recently had to “fix” (workaround) a similar issue in the OpenBSD kernel with a specific hardware peripheral on my PC (running a 2nd-gen Ryzen), the High Definition Audio controller. For whatever reason (and only when I was running OpenBSD) interrupts from the HDA controller (to let the CPU know to refill audio buffers) would just randomly stop making it to the CPU and audio would loop for a few seconds and then shut off. I spent a long time trying to figure out what causes it and reading Linux driver code but I couldn’t find a cause or why only OpenBSD would trigger it. I ended up having to write kind of a hacky polling mode into the HDA driver. My only guess is some of these AMD-chipset-having motherboards have faulty interrupt controllers.

Maybe there is a similar issue with your system and timer interrupts aren’t making it to your CPU or something. But I’m not really an expert on PC architecture and idek if it even works like that on PCs lol

Sorry for so many questions but do you also have any kernel logs available from when this happens?

I simply do both

It’s not working

There are some purpose-built ARM Linux laptops available but as an owner of an unused Pinebook Pro… can’t recommend

Walking the path of a PC hater is not easy

Rip out the fan and connect the processor heatsink to a heatpipe

Then carry around a cup of water to dip the heatpipe into

This is not a bit, I am a real hardware designer

Xorg? Wayland? You have bespoke protocols just for windowed graphics? I’m happy with my /dev/draw and /dev/wsys/*

Unix is a zombie OS that should probably die

That’s definitely not it but it’s very difficult to find research (especially ongoing research is very rare) or even information on alternatives to the currently dominant (due to monopoly) von Neumann, binary, register machine, instruction-set-having, etc architectures.

You might try looking into dataflow, logic-based (like computers that do Prolog), or transport-triggered architectures. Or Lisp machines too.

deleted by creator

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…