I haven't tried BeOS/HaikuOS or the hey tool, but I've used the equivalent on macOS. The hey language seems a bit awkward to me, just like AppleScript. A few years back Apple added JavaScript support for OSA, which was a huge win for me. It took me a while to learn how to navigate the docs and use the APIs, but it's proven to be incredibly powerful.
Over time I've built up a small list of utilities for common UI interactions. Here's an example: Get the list of tabs from the frontmost Safari window [0]. Occasionally I'll be researching some topic with a bunch of tabs open, and I want to go work on something else. When that happens I just grab all the URLs in that window and save it in a text file which I re-open later when I want to continue researching the subject.
IMO, the biggest problem I've encountered with OSA scripts (and presumably it also applies to this hey tool) the lack of REPL and inspector. On macOS you can use Safari's dev tools to debug JS OSA scripts, but it's incredibly brittle. Trying to access certain object properties will just cause it to crash, or it might print the identifier of the thing which you're accessing which doesn't add much value.
The "hey" tool itself is just a command-line interface to the messaging/scripting system built into the Haiku interface kit (that it's essentially built around). Someone once wrote a module for Python to interface with it as well (although it's ancient and I doubt it works with modern Python: https://github.com/HaikuArchives/HeyModule).
I understand not fixing something if it isn't broken, but is there a reason you don't just use a "Bookmark Open Pages" feature? I'm pretty sure it's standard in the big browsers, but definitely on chrome.
I just checked with Safari and it does indeed provide that functionality, and I wasn't aware it was an option.
Honestly, I just find it convenient to get a list of URLs, and dealing with regular text files. Sometimes interfaces are too limiting r slow, and manipulating the list in a text editor ends up being easier.
Another of my use-cases for this is to regroup tabs when I fork into random topics. e.g. Sometimes I end up opening a bunch of tabs that are tangentially related to the subject and I want to move em into a new window or stash em for later.
It's also convenient to grab a manually opened list of URLs in cases where I want to perform some one-off scraping task.
I do something similar with Hammerspoon on MacOS, which allows you to do all of this stuff, albeit with the Lua programming language (which I find far more elegant than anything else) ..
Its gotten to the point that I can't seem to really function on a new MacOS installation without my personal Hammerspoon repo set up .. I'm not sure if thats a positive or a negative result of having such deeply scriptable interfaces, but perhaps it can be looked at both ways.
I use AppleScript frequently, and one of the reasons I can't bring myself to move to Linux is because of the excellent API into every app.
Somehow "hey" just doesn't seem to offer the ecosystem that AppleScript does. Even though I really don't like the latest versions of macOS and iOS, I still prefer the old Apple ecosystem to the fragmented platforms of Windows and Linux (or Haiku).
Mostly text processors. Bash scripting doesn't always handle Unicode nicely. For Pingtype ( https://pingtype.github.io ) I need data in Chinese. I get that from websites. Sometimes I can download it with curl, other times I need to tell Safari to get the source for me. Language syntax like "every paragraph" and "set applescript's text item delimiters to" are much easier to handle than str.split() and IFS.
File reading and writing are easy. Getting and setting track data in iTunes is easy. Finding selected items in the Finder is easy. I've been using more "do shell script" recently as my knowledge of command-line tools increases.
It's slower to run than other languages, but when I just want a quick one-off script to generate some data, it's faster for me to code it in AppleScript instead of spending hours debugging it in another language.
All my processing for PlinyPedia ( http://peterburk.github.com/pliny ) was in AppleScript - splitting the XML into separate files grouped into folders, naming those folders, moving the footnotes to the bottom and adding links to quickly move up and down, and finally generating a basic iUI interface.
I also wrote scripts to transpose chord progressions to Roman Numerals by looking up the values in a table, select cells diagonally in Excel, and turn my Facebook friends list into an iTunes database. (The iTunes database is URL tracks that trigger a PHP script running locally that opens Safari with the URL - it's basically a bookmarks manager with Smart Playlists. If you can recommend a better database, please do.)
Sounds like a good usage case for Perl rather than bash. The former has good Unicode support and you can use the standard lib + Mojolicious to fetch data from the web and serve other data to Safari. No need for bash + command line tools + PHP + web server.
I'm not trying to serve data to Safari (usually), I'm trying to read data from Safari. I often need to get the source of a webpage that's already loaded after a login screen, or with some user interaction.
For example, scrolling down to load all my Facebook messages into the left-hand bar. Or segmenting text into 5000-character blocks, copy-pasting into Google Translate, and getting the output.
With any command-line tools, it would be a hassle, if it's possible at all. With AppleScript, it's easy.
the small titlebar seems neat, but the utility seems diminished (i have a smaller target area via which i can grab a window). does the compactness somehow play into other features of the windowing system, or is it just style?
Having used BeOS back in its halcyon days of the mid-to-late nineties and a as somebody that maintains an active Haiku installation (albeit under VMWare) I have to agree with you.
It is definitely lacking in the browser department (which seems so crucial to most people) but beyond that, it’s a very dependable and responsive OS with absolutely modest hardware requirements.
(I also have a working BeBox 603e 133 MHz but I use it very rarely because I’m very concerned about the health of the IDE HD.)
I played with BeOS when it was still alive, it was light, nice, and fun, and I miss these cute icons, but frankly, I simply don't see the point of reviving it now.
There an insane amount of stuff to be learned from failures. From my understanding, one of the main reasons behind their demise was their business plan. Version for PCs with <256RAM were free, you paid for 256+MB. However BeOS ran so efficiently that no one ever needed 256+MB so few people bought it.
While it's been ~18 years, this doesn't at all sound correct to me. BeOS was a commercial product from its very beginning. There were free "developer release" versions, but it was sold as boxed software from R3 on. The last official release, BeOS R5, had a free version called "BeOS Personal Edition," which ran as an app inside Windows or Linux, but the full version of R5 was still commercial, at $69.95 (with an upgrade discount). I don't recall any licensing requirements pinned to the amount of RAM you had.
A large part of what did in BeOS was a combination of Microsoft's OEM licensing requirements and Be's steadfast belief that the only path to success was pre-installation on a major PC brand. IIRC, if you offered Windows pre-installations at all, you had to pay for every machine that Windows could be installed on whether or not it was actually installed, and you couldn't offer machines capable of dual-booting. Be concentrated their efforts on BeIA, an "internet appliance" version of the OS, which was dead in the water -- according to a lawsuit Be filed against Microsoft, MS pressured their OEMs not to partner with Be on both BeOS and BeIA. (Microsoft settled the suit for around $24M, IIRC.)
Personally, I think BeOS might have been able to survive as a niche OS if Be had kept their focus solely on it, kept the price competitive with boxed Linux distributions (those were a thing back then), and not been dedicated to the "go big or go home" mantra, but I don't have any inside info to prove (or disprove) that.
I was one of the people who worked at Be, right up to the very end, when the company went out of business, got absorbed into Palm, and I was laid off. I remember all this the same way you do.
... Except that I don't think there is anything they could have done that would have made them successful, at that point in time, other than possibly not playing hardball when Apple came calling. Microsoft's stranglehold on the industry was just too great.
I just wanted to let you know that to this very day I mourn the loss of Be Inc and BeOS. Whatever work you did there I’d like you to know (that for me at least) it was worth it because it left an enduring impression on those of us that had the privilege to use the system.
Unfortunately, I didn't do much to move BeOS further down the field. By the time I got there, the company had given up on BeOS as a standalone consumer product and was squarely focused on BeIA, specifically the Sony eVilla. (you can google it for the whole sad, sordid tale, if you dare.)
My contribution to the ecosystem, if in fact I ever made one, was to write what I thought of as the best USENET newsreader available on the platform.
I'm a huge BeOS fan (my BeBox still works) and in my opinion the one thing that Be, Inc. could have done to stay alive, and the only thing, is this: focus on making innovative hardware.
They didn't - the decided that hardware is too hard, and JLG lost the momentum - but if they'd made a BeBox that people actually wanted, they would definitely have survived in my opinion. A Laptop-format BeBox, for example, would have had an opportunity to really dominate the field video world, in those days.
I also have a working BeBox (dual 133 MHz 603e, 32 MB RAM), but I’m a bit concerned about the IDE drive (640MB). The CD-ROM drive doesn’t work very reliably anymore either, unfortunately. I even have some peripherals I soldered together for the GeekPort way back in 1997-1999.
Beautiful machine. Wonderful operating system. Pity they were so inept commercially. That said, I was also a NeXT user, and I’m convinced that Apple wouldn’t have returned to the forefront if they had chosen “Plan Be” instead of the Steve Jobs option.
> "BeOS R5, had a free version called "BeOS Personal Edition," which ran as an app inside Windows or Linux"
Not quite. While the file system resided on the Windows or Linux partition as a drive image, to run BeOS you rebooted the computer into BeOS natively; the boot loader booted that drive image from the other OS's file system.
In fact, once in the BeOS environment, you could use the BeOS disk manager and installer to create a BeOS native partition on free space on the main drive or a second drive, and install the OS natively to the PC. Effectively, you could run the full OS on its own for free.
That's exactly what I did for the first few months I used BeOS back in 2000; I was so taken with the OS I bought the full version and tracked down a hard copy of the BeOS Bible and Be Advanced Topics, both of which are still on my bookshelf.
> "I don't recall any licensing requirements pinned to the amount of RAM you had."
There were no licensing restrictions that I was aware of, however it wouldn't run on machines with more than 768MB without a patch.
Back in the mid-to-late nineties I had the fortune of using both BeOS and NeXTStep. I loved both operating systems and recognised their differing strengths and weaknesses.
I must say I was hugely disappointed when Apple chose not to pursue “Plan Be” and opted to purchase NeXT instead. The operating system seemed like overkill and not a good match for Apple’s use-case (single-user machines, media-focussed workflows, with an obvious advantage to be drawn from pre-emptive multitasking and almost real-time multimedia processing). NeXTStep struck me as a much more “workstation-type” OS that would have had little resonance on the consumer and professional market.
It turned out I was wrong: Moore’s Law has made the heavyweight NeXTStep an eminently shoulderable burden, and that it is now so “lightweight” in relative standards that its direct descendant (iOS) can comfortably run on (albeit unimaginably powerful) mobile devices.
I wrote elsewhere in this thread that with the benefit of hindsight I don’t think Apple’s resurgence could have happened had they had chosen Plan Be.
Yes, they picked Steve Jobs, and NeXTSTEP was quite advanced with ObjectOriented-UI and its UI-builder - most of the stuff is still there with a new Theme and called MacOS X. Companies like Pixar used NeXTSTEP.
BeOS was quite interesting too. Though it lacked multi-user support, and had a small user community. Its BeFS filesytem had an indexing feature that dwarfs all desktop search features even today - and Windows "Cairo" (1996) / WinFS (2006) that tried to accomplish it too, turned out as vamporeware.
Both NeXTSTEP and BeOS were ahead with multimedia support like real time video player and WYSIWYG editor.
"... "Vaporware" was coined by a Microsoft engineer in 1982 to describe the company's Xenix operating system, and first appeared in print in a newsletter by entrepreneur Esther Dyson in 1983. It became popular among writers in the industry as a way to describe products they felt took too long to be released. InfoWorld magazine editor Stewart Alsop helped popularize it by lampooning Bill Gates with a Golden Vaporware award for the late release of his company's first version of Windows in 1985.
Vaporware first implied intentional fraud when it was applied to the Ovation office suite in 1983; the suite's demonstration was well received by the press, but the product was never released. ..."
I've been part of the BeOS community since 1998 and I have no idea what he's talking about. Other than R5 Personal Edition, x86 BeOS was never free.
Be failed because it existed in the times of Microsoft dominance, Apple didn't buy it, and it had some major technical deficiencies (many of which have been addressed in Haiku).
That document mentions that R5 Personal Edition had a disk partition size of 512MB. That's disk, not RAM.
R5 PE had that partition size because it installed to a 512MB file within your Windows partition, then booted from that file. Personal Edition was meant to give a way to try BeOS without having to have a second drive or do any partitioning. Once booted into it, you could just launch the Installer app and install to any size partition you pleased.
Be was essentially dead decently before R5 was released, so I disagree with the author's conclusion.
You are right, its been a while and my memory is hazy. It's not that I cant tell them apart, it's more that I read it a couple years ago and it just doesnt come up and I apparently can't be fucked to look up the docs.
NeXTSTEP never caught on and was a commercial failure. macOS is based on it.
Netscape Communicator was open-sourced after it fell to Microsoft and later became Firefox.
Not everything that dies deserved to. Successors are not their predecessors. BeOS provided a good base for developers to work towards, so the project wouldn't get bogged down in trying to be "something new".
The same has been said countless times over the decades for things like "Unix", or "Linux" or heck .. even Windows in some quarters.
I don't think there's anything 'wrong' per se with having alternative operating systems - they may not get mainstream approval, but a lot of what is now mainstream started out as fringe/horizon technology. And in that regard, we ought to encourage the fringe to share their discoveries - it does eventually trickle down.
(Disclaimer: you can have my BeBox when you pry it from my cold dead hands..)
Over time I've built up a small list of utilities for common UI interactions. Here's an example: Get the list of tabs from the frontmost Safari window [0]. Occasionally I'll be researching some topic with a bunch of tabs open, and I want to go work on something else. When that happens I just grab all the URLs in that window and save it in a text file which I re-open later when I want to continue researching the subject.
IMO, the biggest problem I've encountered with OSA scripts (and presumably it also applies to this hey tool) the lack of REPL and inspector. On macOS you can use Safari's dev tools to debug JS OSA scripts, but it's incredibly brittle. Trying to access certain object properties will just cause it to crash, or it might print the identifier of the thing which you're accessing which doesn't add much value.
[0] https://gist.github.com/cesarandreu/8d6ccd70bcac81d1a45941ae...