waddlesplash

8 ms·

31.
by waddlesplash 4y ago
There's a non-built-in solution in axeld's DriveEncryption, but it doesn't support encrypting boot disks. Probably we should try and incorporate DriveEncryption into Haiku itself and see about adding support for boot disks...
32.
by waddlesplash 4y ago
GNOME Web has built-in adblocking.
33.
by waddlesplash 4y ago
Sometimes it is, and you can see elsewhere I've given real answers to that question. But sometimes my criticisms of Linux are because, well, they are a real and genuine motivation for why I gave up on desktop Linux and devoted even mor
34.
by waddlesplash 4y ago
Free-for-all in terms of toolkit and application mix, yes, but that's actually the "lesser" problem of the Linux desktop. Ideally we would have all-native applications, but not even macOS can really manage that. The X11 and W
35.
by waddlesplash 4y ago
I think you are reading a little too much into it. Linux people throw darts at Haiku ("why would you ever use this and not Linux?" etc.) so it seems only fair we throw a few back. Many of us have desktop Linux installs, and some o
36.
by waddlesplash 4y ago
Uh ... no? The release notes state it started out using the X11 layer, but then switched to using the Wayland layer. I should know: I wrote the X11 layer, contributed to the Wayland layer, and wrote most of these release notes. :)
37.
by waddlesplash 4y ago
It's an alternative to the fragmented state of the "Linux desktop": instead of having dozens of separate projects (GNOME, PipeWire, systemd, Wayland, ...) be combined by yet another project (a distribution), which is (in my v
38.
by waddlesplash 4y ago
R3 could actually run on Intel PCs; it was the first release to have that option available. The other two you are probably right about, I'm not actually an expert in BeOS history pre-R5 :)
39.
by waddlesplash 4y ago
There's not a Linux ABI emulation layer but it is running on top of a Wayland emulation layer, instead of using the Be GUI API directly (as the Qt, SDL, and Java Swing ports do.) That does make a difference, especially around stuff lik
40.
by waddlesplash 4y ago
It's not just that there was something magical to BeOS, there's still something magical to Haiku, especially in the era of the "Linux desktop" with its free-for-all fractured ecosystem approach to desktop environments. W
41.
by waddlesplash 4y ago
The ARM port has made a lot of progress since the last release; it gets almost all the way to starting the desktop. Similar progress was made on ARM64. But that's not very exciting news, so it only got an oblique mention in the release
42.
by waddlesplash 4y ago
Have you tried the newly-ported GNOME Web browser, mentioned in the release notes? It seems that it solves the "web browser problem" many users have complained about.
43.
by waddlesplash 4y ago
The front-page should probably have more screenshots, yeah. There's a screenshot tour here: https://www.haiku-os.org/slideshows/haiku-1/ And the release notes, linked from the release announcement, have scree
44.
by waddlesplash 4y ago
The ARM64 port doesn't yet boot all the way to desktop in QEMU, so it certainly won't run bare metal on an M1, unfortunately. You can certainly dual-boot it on x86 machines, though.
45.
by waddlesplash 4y ago
That would be "stippi" aka. Stephan Aßmus on both counts, I believe. At least the icon style was chosen after a competition all the way back in 2006, where stippi's style got the most votes [1]. The look & feel of control
46.
Haiku R1/beta4(haiku-os.org)
440 points by waddlesplash 4y ago|139 comments
47.
by waddlesplash 4y ago
Release notes: https://www.haiku-os.org/get-haiku/r1beta4/release-notes/ Downloads: https://www.haiku-os.org/get-haiku/r1beta4/
48.
Haiku Activity and Contract Report, June 2022: 802.11ac WiFi(haiku-os.org)
5 points by waddlesplash 4y ago|0 comments
49.
by waddlesplash 4y ago
Yes, it's probably easy to identify the Haiku-specific bits and start replacing them, but some of the organization of e.g. the Drawables classes is kind of implicitly built around Haiku APIs, so it might be a little less trivial than i
50.
by waddlesplash 4y ago
> I would really advise against making these kind of comments if you're trying to represent a project or get more funding. Look, a little snark never hurt anybody. The fact is that you are being extremely pessimistic about whether t
51.
by waddlesplash 4y ago
> But from this comment it actually does sound like you didn't look at the GTK4 codebase. I gave it a cursory glance, but indeed I didn't look at it much in depth, because all the big GTK-based applications don't yet run o
52.
by waddlesplash 4y ago
And I forgot to mention, how silly of me: This work was largely done under sponsorship from Haiku, Inc. ( https://www.haiku-inc.org/ ), the non-profit that manages the financial/legal aspects of Haiku development. If you
53.
by waddlesplash 4y ago
Yes: the GTK codebase is, uh, not fun to work with and write backends for. See my comment above ( https://news.ycombinator.com/item?id=31192099 ) and also one of my replies on the Haiku forums ( https://discuss.haik
54.
by waddlesplash 4y ago
> Was fixing that the intent behind libxcb? Yes. Like I noted in another comment, XCB is basically just a loose wrapper around the X11 protocol. It is indeed a lot more verbose than Xlib, and modern Xlib is actually written on top of XCB
55.
by waddlesplash 4y ago
> If all you care about is GTK, then you could have just done a native port of GTK. That would actually be a lot easier than trying to reimplement every X client library. LOL! Do you really think I woke up one day and said "hmm, I n
56.
by waddlesplash 4y ago
> How hard would be to abstract the Hauku-specific bits into their own part? Hard, as I mentioned to other commenters, Xlibe makes heavy and direct use of Haiku APIs everywhere to do just about everything. However... > It'd be ne
57.
by waddlesplash 4y ago
> If this is being done for practical reasons then don't waste your time with this. Too late, I did, and it's already being used "in production" to power GTK on Haiku! > It might work for some clients Well, GTK was
58.
by waddlesplash 4y ago
The graphical Emacs backend, unlike the rest of the things you mention, was not developed by one of the "regular Haiku developers" but by one of the Emacs developers, and fully upstream, too, which makes it doubly exciting. Indeed
59.
by waddlesplash 4y ago
> Thanks for clarifying. I assume the reason you implemented at this level is because it was a better match for Haiku's graphical APIs? It's possible to integrate with the rest of the system much more smoothly than a full serve
60.
by waddlesplash 4y ago
> So this is a compatibility library? Not just a server that runs without a root window? Correct! > I don't have a Haiku box handy to test - is Xephyr any easier/better? It seems to be the "modern" option. Both Xne

More ›