The thing is that the learning curve for any tech has never been easier. You can ask a question and AI will help/tell you which command can answer that question. You can write that down. You can poke around the system.
You can ask how your current automation code handles XYZ situation to get a better understanding, then ask if a code patch (you're working on) would help with ABC (i.e. get it reviewed), and so on.
It has never been easier to be a junior dev.
The point about needing manual "practice" is on point, yes, you need hands-on time.
To me it's not nostalgia, the system felt truly great to use. Haven't met anything as good since then.
And while I agree that Steve Jobs and Next were the right business (and people) choice, I still mourn the loss of a much better UI (never been a fan of the Mac UI, and it's my daily at-work system).
I'm not familiar with Be API, but I did a lot of GUI dev in Java Swing back in the day. It's not that hard in principle, you launch whatever background op in whatever threads you like, and any GUI updates have to be done by sending messages back to the GUI event thread (or something like Swing.invokeLater(closure)).
Yes, Be GUI is heavily multithreaded, so core dumps were kind of common, and stuff like Swing.invokeLater(closure) only came later in Swing, after existing for a while as community library, after folks having the same issues in Java GUI applications.
Note that on Android they took an hammer solution, programming patters to invoke such code on main thread, have as outcome that there are either lint compile errors, or platform killing the application, for those flows not verifiable at compile time.
Yes, and it’s been a quarter century or so but this is how I remember BeOS doing it. Every window got a dedicated thread for handling events and GUI updates, and other code would communicate with it via message passing. The OS had a standard message passing system that was pervasive; if I remember right every thread got a mailbox by default.
But it was 90s era C++, so probably that was all just a polite agreement and the reality was that circumventing the message passing to directly call methods on objects that belong to other threads was common, and just as likely to happen by accident as on purpose.
Yep, reeeally nice feature, used it on Linux. After that I wondered why apps bothered to implement their own tabbing when you could just stack Windows as tabs (assuming more WMs would adopt that feature).
To me BeOS was and is still the best looking desktop OS ever, and it was so fast, it felt so good. I think in 2000ish (when it was released freely) I used it on my PC pretty much exclusively for a few months.
GNOME 3 was trying to built a clean modern minimalist desktop without all the clutter inherited from the design of Windows... But all they know is, very visibly, Windows and KDE.
RISC OS is that clean legacy free desktop. It's unlike anything else, built from scratch by a team not interested in what the rest of the world was doing.
And it's still alive and still updated and works well on modern hardware. Several separate efforts are building 64-bit replacements today.
Uh, legacy free? I'd argue the opposite - it's got tons of legacy baggage - cooperative multitasking, and a lot is written in old ARM assembly language. It's disk limitations, filetypes.
> And it's still alive and still updated and works well on modern hardware.
I am quite impressed that the bounties that are put out to improve it get funded. (to be clear, this is not sarcasm , there's tens of thousands of pounds £s donated). I've tried in on my Pi, and it's super snappy, if a little odd.
Many people might not know that ARM the company behind pretty much all phone CPUs (at least historically) was founded as Acorn Risc Machines and built their own computers with their own RISC OS.
I know almost nothing about it, so I will give your links a read.
It runs on all Raspberry Pi models up to the 4, and runs really well. As of version 5.30 it supports the Wifi chip in the Pi so it can connect to WLANs.
The owners of the IP are RISC OS Developments Ltd (ROD) and they have an enhanced version -- free on the Pi -- called RISC OS Direct, with an IPv6 stack and a modern WebKit browser:
There is another fork of the OS that is still proprietary. That's owned by 3QD. They used to sell upgrades for real Acorn-compatible kit but there's none of that that isn't vintage now, so it focuses on a software emulation that runs on modern x86 machines:
Search the Reg for "riscos" and you'll find interview with the original core team, looks at the last couple of FOSS releases, the Moonshot effort to go 64-bit and more.
> I wish that there was some edict from KDE Project management telling everyone working on the Plasma desktop to spend a week in Haiku or something.
The other thing is that it says right at the start of the BeOS Book - and this is carried across to Haiku - is that you shouldn't have a spinner or hourglass. It should do *something*, it shouldn't make you wait.
Dedicated user account does not work as eventually all your code and data will move under that.
I run it in an ephemeral container sandbox (https://github.com/ashishb/amazing-sandbox) which has access to the current working directory and it drastically limits the attack radius.
It is good but you still don't want long running background tasks.
When you run a linter, for example, then it should stop executing cider once it stops. And not be able to spawn long-running background tasks for infiltration.
Docker is still a skill if you want to build your containers without AI help.
reply