Antique BeOS Content by Scot Hacker (2011)
birdhouse.org
birdhouse.org
> From the stance of a commercial vendor creating a commercial product, the open source world holds other barbs. For example, if components of your system link against libraries that fall under the GPL, you may be forced to release your own system -- or parts of it -- back to the community as open source software. In other words, building a proprietary solution on top of Linux may mean being required to expose the company jewels to the competition. Witness TiVo, who manufacture a time-shifting hardware/software solution for television consumers. Because TiVo is based on Linux, the company's modifications to the kernel are available for anyone to download -- any competitor can emerge at any time, packaging up and selling a variant of Tivo's hard work.
One could almost forgive him to say something like that in 99, but the ones who are still repeating the exact same reasoning today should probably think twice...
His argument wasn't rare back in those days though (we're talking about a time where Microsoft was still dominant and actively hampering the FOSS movement), and it was an argument for BSD license as well.
The way companies have worked around GPLv2 and GPLv3 is Web 2.0/3.0: HTTP(S) and HTML/JS being proprietary software, though the source is readable, and the entire stack behind it (ie. akin to LAMP) which generates the data having the ability to be part of a closed source or proprietary ecosystem. They furthermore locked it down with things like paywalls, apps (instead of website or PWA which might give the users some power back). In such a world, how can us mere mortal users even verify things like GDPR?
The FSF foresaw this, btw, and IIRC (at the very least free software advocates foresaw it) considered having the GPLv3 apply on protocols like HTTP(S). That didn't fly though, and resulted in obvious backfire as well because it went against the business model of many for profits...
Actually Linux is licenced only under GPLv2:
> The only one of any note that I'd like to point out directly is the clarification in the COPYING file, making it clear that it's only _that_ particular version of the GPL that is valid for the kernel.
> ...
> Why? There's been some discussions of a GPL v3 which would limit licensing to certain "well-behaved" parties, and I'm not sure I'd agree with such restrictions - and the GPL itself allows for "any version" so I wanted to make this part unambigious as far as my personal code is concerned.
Source: http://lkml.iu.edu/hypermail/linux/kernel/0009.1/0096.html
Making a logically sound argument?
Am I making a sin if I complain about the GPL or Tivo? I honestly don't get it. The quote basically says "don't use GPL stuff if you don't want to give away your work" which seems very simple and logical to me. Everybody knows this. What is so bad about saying it?
EDIT: Oh, it was you who said it and you're being more obscure now than you were when you made the comment. Can you not explain what exactly is your beef?
> Be has quietly been planning their own version of the perfect low-cost, easy-to-use, dedicated media device. Be's IPAD (Internet Personal Access Device)* > [...] > * According to hints dropped in a recent newsletter, Be may be casting about for a catchier moniker than "IPAD."
But also a good read for millenials and such who have a hard time understanding why some of us older guys really dislike Microsoft.
There's lots of recent reasons to really hate Microsoft now.
- Forcing Windows 10 on users.
- Forcing telemetry on people and making it almost impossible to disable.
- Saying they <3 Linux, but refusing to port their actual good products (MSO, or Visual Studio) to Linux. So that they can keep their vendor lock-in.
- Not adhering to their own standards, to make it difficult for Office documents to inter-operate with other office suites.
- Windows 10 switched to a rolling release model, which is nice. But the updates are forced, so that fucks you over as a user, because you can never be sure if your system is stable.
edit:formatting
I disagree. Not only are constant changes destabilizing to the user, they're destabilizing to developers too. I really don't get why so many people (Linux Desktop users especially, so maybe they're all webdevs?) love them so much. Once I have a system set up for my workflow, I don't want it to go and screw it up by changing things unnecessarily.
On Linux you can choose to never update ever, if that's what you think is best. You are fully in control.
As for why I like rolling release:
- It's much nicer never having to update your "whole" OS. It takes a long time, and you need to do backups in case the upgrade fucks things up.
- I like having up-to-date software
- Your workflow doesn't change like you say it does. I've been using rolling release OS's for the last 3 years, and my workflow hasn't changed since I started. If there's an update to a package with breaking changes, and you don't want to deal with it, then just don't upgrade that package.
I don't either but my guess is they are running it on their personal machine which makes the risk of something breaking less of a concern. At home i'll run the latest and greatest but at work I stick to LTS releases and just compile from source the few packages I want/need with newer features.
Linux is the only modern OS that doesn't do this, all OS updates are forced it's just some are forced more gently than others.
I have to postpone the the OS X update dialog daily and the iOS one about once a week. This has to be done carefully because if I press the wrong option it'll update itself in the middle of the night.
Along about 1998, I decided I'd had enough of Microsoft's antics, and started looking for an alternative OS ecosystem I could participate in. I tried a lot of things, and wound up on BeOS. I'd probably still be there, if Microsoft hadn't killed it.
"Other important languages, such as perl, have also been ported and are fully functional."
"Thus, BeOS applications are currently scriptable from both bash and Python."
18 years ago. Perl and Python.
http://birdhouse.org/beos/byte/24-scripting_the_bfs/
$ ThisCity=$(catattr META:city "$This Person" | cut -f3 -d:)
The value of $ThisCity is now "Munster Hamlet" whenever the script is passing over the file "Walter Mitty."
Perl 18 years ago is pretty standard.
Funny how the 4:3 video windows look dated these days.
16:10 or 16:9 have the convenience that (at fixed diagonal) they have good support for multiple columns, but this comes at a severe cost to vertical space & total surface area.
Though IIRC for some types of FPS widescreen resolutions is also good (as long as the FOV is configurable) as it gives a wider field of view.
I had a BeIA device and had a few versions of BeIA running on various other devices. It was pretty much just BeOS without the Tracker desktop and with a slightly different file system. Take a look at Wikipedia ( https://en.wikipedia.org/wiki/BeIA - I wrote a lot of the BeIA info back in the day on there, especially the stuff about the CFS and exe compression.) The DT-300 Webpad I had was nothing really like an iPad (it was running a Geode from NationalSemi and booted from a compact flash card.) But you can see where the tech was heading.
After I left BeOS behind, I haven't heard his name very often, but I still appreciate his advocacy for BeOS.
It's a shame all of the BeNews content was lost to a database failure, though you can still find bits and pieces in the Wayback Machine..
One item of curiosity was how they were able to so efficiently handle media with such a light footprint? What were the trade-offs? For devices like tablets, it seems like it would be a godsend.
Also, did any of the innovations make their way into things we use today? Palm bought their tech, but did any of the media tech make it out? Or is it just an artifact from an earlier age with not much applicability to modern day needs?
The biggest one was: freedom from backward compatibility. You can't comprehend how much cruft you are drowning in, in your typical OS, until you are free from it. Coming to BeOS from Windows, as I did, it felt like 2,000 pounds was lifted off my shoulders.
BeOS was free to fully embrace some modern technologies that had been bolted on to older operating systems as an afterthought. The biggest one was multi-threading. Having spent years on earlier operating systems, I can say that all of them have a stunted idea of multi-threading, compared to BeOS. Typically, you are forced to run your user interface in your main thread, and you have to run background tasks in background threads, and invent ways to communicate between the two.
Contrast BeOS: every single window runs in its own thread. Think about that for a minute: If you write a BeOS app that has two or more windows, surprise, your app is multi-threaded. Whether you like it or not! A lot of programmers, coming from older operating systems, very much did not like it. Personally, I came to embrace this as BeOS' greatest strength. Communicating between windows was pretty natural: just drop events into each other's event queues, which were of course thread-safe.
Unfortunately, the early architects of the system made their own set of poor decisions that led to a new round of cruft. The worst of these was tying themselves to the ABI of a particular C++ compiler. GCC version 2.9x, I think. In the last year of Be's existence, we were really feeling the pain of this. The compiler we were shackled to was many years out of date. If we switched to a modern compiler, it would have a different ABI, and all older software that couldn't be recompiled would have been instantly broken. Nonetheless, there was a vocal minority of engineers inside Be who argued for doing just that. We weren't focused on external users at that point, just internet appliances, so we could have gotten away with it. But we were all BeOS users ourselves, so we would have lost a lot of useful apps that way.
Could there not have been a compromise for those devs who didn't want ABI compatibility? For instance with Apples handling of Mac OS apps and then carbon and then cocoa?
Meaning, some sort of optional emulation layer? Of course, the system architecture may be so different as to make it impossible, OR the business decisions needed at the time couldn't afford a middle layer.
Either way, this was one of my favorite comments on here, so thank you :)
You could get a much fuller answer by exploring how Haiku handles this. I haven't paid much attention to that OS in quite awhile, but I think they did indeed succeed in keeping a set of backward compatibility libs, for older software, and also built a new set of libs for recently-compiled software.
The crushed apps have a magic symbol CEL instead of ELF in the file header.
The file system was also compressed. It was called CFS, rather than BFS (BeFS) and a lot of stuff like attributes and metadata was very broken in the pre 1.0 builds I saw.
If I am remembering correctly, we used uncrushed binaries and a non-crushing kernel while developing on our own PCs. (We used plain-vanilla garden-variety Intel PCs to develop on. Very few developers needed to interact with the actual BeIA devices.) The crushing part didn't happen until somebody on the build team was building the final binaries to go onto the BeIA devices.
Sometimes, the crushed build process wouldn't work! It was super finicky. That would prevent a test build from going out when it was supposed to, and the testers would have to twiddle their thumbs for awhile.
Other than that, I can't tell you much about it. I was a lowly application engineer. I didn't have to get into all the picky details about how the kernel interacted with apps.
I also know that the OS was a bit quirky in so much as some of the R5 API's were missing, or closer to the R4.0 ones at least. The File System was definitely flaky.
I started to write this app to do PalmOS style handwriting input for the DT-300, but I ended up selling it on to finance some other project before I finished it. https://github.com/memsom/ratcowsoftopensource/tree/master/B...
Question/observation - with the CELF (Crushed ELF) format, would that not have been enough to make moving the compiler either justifiable (you were crushing the EXE, so the format was different anyway), or impossible (the tools would need to be altered to handle the newer format)? I kind of think the former. I don't really know enough about how the apps were crushed (other than that it was a real PITA if your OS didn't have a map* dictionary* with the right symbols in it.)
* Been over 10 years and everything I learned I learned from hacking on BeIA after Be closed shop as an enthusiast, so forgive me if I use the wrong terms.
the Be Newsletter archive : https://www.haiku-os.org/legacy-docs/benewsletter/
I read these all back in the day. They are an amazing time capsule for the BeOS and what was going on at Be during the mid - late 90's and early Noughtiess.