> More sensible, IMHO, might be to bolt the FreeBSD user space unto the Linux kernel.
Chimera Linux is doing something like this, although without aiming for the full BSD experience, just utilising its core userland [1]. The project is in an alpha stage.
I have two accounts in my name, one for me personally and one for work. I got the offer on behalf of my employer, and was like; what would this even mean for this account? I'm pretty sure I would take the offer had it been for my personal account.
You missed the second sentance. The length of the translated string is less critical for a tooltip compared to a toolbar filled with buttons.
Imagine when an app is to be translated to 20 languages. Only the original language had the luxery of having a voice in how many buttons fit on the toolbar.
> How are you going to play music you've added in the last three years, but not heard for a month, from the "Latin" genre, with two or more stars, using only the file system?
BeOS actually solved this 20 years ago with its file system BFS. Haiku is an open source reimplementation of BeOS that recently progressed from (high quality) alpha releases to its first beta.
Ok, good to know, thanks. The point still stands that the receiver's client probably doesn't bother styling the message. I mean even if GMail, say, was persuaded to do it, Outlook for instance wouldn't.
That would be nice if it was standard for clients to display text/markdown rendered as styled text. This would require an actual standard for the markdown syntax though. Without the rendering, markdown is just text/plain.
Are there any mail clients that will send both the markdown source and the rendered HTML as a multi-part message?
That would mean two stages of password query, which I think might be a con. Also, the file names would either not be encrypted in the git repo or not be compatible with e.g. Android app I guess.
Thanks for the autofs hint, will try it and see how that works out re unlocking.
For this reason I'm thinking of switching from gpg to encfs. It has an option for auto-unmounting after a period of unactivity. It would also play well with programs that need to read password from a file.
Has anyone else here had the same thought? This guy seems to at least;
I guess the next OS revision you mention would be "Dano", which according to the Wikipedia article[0] was leaked on the day the company closed down. In that case, there should be quite a number of screenshots floating around, such as [1]. YellowTAB Zeta[2] was also based on Dano.
The very first web browser had editing built in. That's why HTTP has the concept of verbs in the first place! Otherwise GET would probably be implicit. Forms and POST came later, but PUT and DELETE was part of the original idea behind the web.
I totally agree that browsers should allow editing. Even if you are not authorized to PUT the page back to the server, it would still be useful to be able to edit before you print or save the page locally.
I really have no idea why we were robbed of this capability! It was probably just laziness from the people who wrote mainstream browser and httpd implementations.
Chimera Linux is doing something like this, although without aiming for the full BSD experience, just utilising its core userland [1]. The project is in an alpha stage.
1: https://chimera-linux.org/about#alternative-userland