Funny how he talks about TiVo well before the advent of GPLv3, but as a victim:
> 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...
That's just an argumentum ad misericordiam (appeal to pity, sob story). These modifications to the Linux kernel weren't even the core of the TiVo product, and the TiVo product was an end user solution consisting of hardware, software, and support (so a full stack, like an Apple TV or an Nvidia Shield). He's also ignoring the patent argument, and the fact that the Linux kernel is licensed under GPLv2 or later (EDIT: I stand corrected; licensed under GPLv2. That doesn't change the point though).
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...
> ...the fact that the Linux kernel is licensed under GPLv2 or later.
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.
I don't follow you at all. I wish someone would just come out and make a straightforward remark about this because I don't see what the fuss is about.
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?
Interesting mention on the BeOS-based IPAD prototype in 1999:
> 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."
> 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.
> Windows 10 switched to a rolling release model, which is nice.
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.
Those are the problems with rolling release on Windows, because they are forced.
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 really don't get why so many people (Linux Desktop users especially, so maybe they're all webdevs?) love them so much.
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.
> But the updates are forced, so that fucks you over as a user
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.
Indeed! I was working at Be Inc at the point when they were absorbed by Palm and went out of business.
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.
Eventually the beta will ship (probably this quarter) and there will be a few folk trying it out in earnest. Since the browser mostly works, I expect it to be rather popular as such things go...
The beta is very likely to happen by Q2 this year. All of the release blockers are pretty much done. The big blocker was getting the package manager in shape, and setting up official build bots and repositories. These are done now. I am optimistic that the beta branch will happen in the next month or so.
Indeed. The "tallest" resolution for laptops these days the rare 3:2 (surface laptops, possibly also the HP Spectre x2), followed by the odd 16:10 (actually is there any laptop manufacturer using 16:10 other than Apple?).
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 was heavily in to BeOS. I read Scott's BeOS Bible cover to cover. I had most of the other books (The BeOS API gude, Advanced topics, Programming the BeOS, Practical Filesystem Design) and also had a BeBox (a 66MHz model) and a PowerMac 9500/180MP (Dual processor) to run the OS on. I had a lot of fun. I advocated PowerPC back when the trend was towards Intel and I still mess about with the OS occasionaly ( https://github.com/memsom/mwobdec .)
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.
In addition to the BeOS Bible, Scot Hacker also created the BeOS Tip Server, which was a great resource at the time. He also wrote a book for O'Reilly on MP3 (MP3: The Definitive Guide) that I found very useful. And he created RipEnc, a BeOS/Bash shell script to rip CDs to MP3 while making use of BeOS metadata.
After I left BeOS behind, I haven't heard his name very often, but I still appreciate his advocacy for BeOS.
I still have his The BeOS Bible on my bookshelf. I don’t know why, really. (For context, I also have Inside Windows 2000 and Mac OS X Internals: A Systems Approach, all of which are pretty dated.)
I remember reading about BeOS and seeing demos during 2000-2001, but I always wondered a few things.
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?
I worked at Be for almost a year, and used BeOS for a couple of years before that. I am not an expert, but I can mention a couple of things.
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.
This comment is such a perfect example of the reasons I come to read the comments here on HN. Thank you for the info.
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 :)
I suppose it would have been possible to build some kind of API shim that would allow for two or more ABIs. Alas, the technical details of how to make that work are above my pay grade. I can say that it never came up in the heated debates I heard inside Be. Possibly because that would have meant the base OS would have been a lot larger, and we were targeting resource-constrained internet appliances at the time.
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.
BeIA was quite clever. The OS compressed the binaries by using a one way (?) process to pull out common code segments in to a common dictionary. The OS then read that code somehow in to memory when the apps started. You could run the OS uncrushed, but it took up a lot more space. One could fit the entire OS on a 16MB CF card in crushed format. (YES, MB not GB!!)
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.
I had completely forgotten about that "crushed" business, but you just reminded me.
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.
Yeah, the tools I had were picky. The size of the OS partition was very specific - it had to fit on to a multiple of a CF card I think. There was some kind of hard limit of about 32MB or something like that. I know I had it all running on an old Compaq PC at one point, but the bootloader would only boot if it was the only OS on the drive, so that was a bit of a pain in practice. I probably still have the OS images somewhere.
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 guess the great intel compiler switch had already happened between the old PE based Metrowerks and the "new" gcc. I can vouch that stuff from PR1/PR2 still more or less runs under R5.03 on PowerPC (for example, I managed to get the Metrowerks Java implementation to "somewhat" work under R5.) But stuff from the R3 Interl relelease really just does not work on R4.0 Intel because of the compiler change. I guess if it was still ELF base, it might not have been so bad.
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.
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.
> 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...