return_0e

I can't change the link now but this should be the correct link to the post: https://discuss.haiku-os.org/t/progress-on-porting-firefox/1...

Not an optimising one (yet) but a safe implementation of a malbolge interpreter written in Rust, which can run malbolge programs. Just for fun.

https://github.com/return/malbolge

Yes, I find that The Dragon Book to be a fundamental reference in my university days of studying compilers. Even so, many sections of it are still relevant to this day.

Also, I think I might have seen your name before whilst looking at the Solaris port of Go years back. Mind you, I'm looking at bringing Golang to Haiku (0) with similar changes like Solaris and Windows.

(0) https://github.com/golang-haiku/go/tree/golang-1.11-haiku

This is very interesting as this is almost identical to how the Haiku Operating System does package management using their own packaging format (hpkg) which uses packagefs. [0] [1]

This format is used more than just to package applications, but to update the whole OS in a consistent manner [2] as it is also versioned in with shared-libraries and this was implemented in 2013.

[0] https://www.haiku-os.org/blog/zooey/2011-01-08_package_manag...

[1] https://www.haiku-os.org/guides/daily-tasks/install-applicat...

[2] https://www.haiku-os.org/blog/bonefish/2011-06-20_package_ma...

I haven't implemented PASETO but I was thinking about adding support for another language. If I were to implement it, I would just use libsodium for most of the cryptographic primitives whenever possible since the reference PASETO implementation uses it as well as most of the other language implementations too (Except for the Go version).

PASETO does seem like a cryptographic secure alternative that addresses the pitfalls of the JOSE standard and has most of the mitigations mentioned in this blog-post (No cryptographic-algorithm agility) and it supports the same functionalities of JWT/JWE and JWS. So I am convinced on getting that standardized, but it also needs XChaCha20-Poly1305 AEAD to be standardized too [0].

Fernet was also around as being a secure alternative, but it has been mostly replaced by Branca [1] and PASETO.v2.

[0] https://github.com/bikeshedders/xchacha-rfc

[1] https://branca.io

Newgrounds.com [0] is a community of artists, creatives and game devs that still use Flash for their content and they are still alive and well today.

[0] https://newgrounds.com

As for virtualization, Fuchsia already has its own KVM equivalent called Machina which so far can run Debian on top of Zircon and with several compatibility changes for supporting the ART runtime in Zircon already merged in, it should be also possible to run Android apps with this.

But perhaps the reason Fuchsia won't struggle unlike the other OSes you mention, is that it is possible that it will be compatible to run all the Android apps in the play store from day one, thanks to Machina; allowing a smoother transition, a process similar to what Apple did with the PowerPC to X86 switch but in Google's case, its for a completely different OS.

Haiku has Python 3[0] (at 3.6.7 IIRC) which can be installed from the package manager.

[0] https://depot.haiku-os.org/#!/pkg/python3/haikuports/3/6/7/-...

..but XNU is now open source.

Well XNU has always been 'open-source' [1] for some time on Intel machines but its just that ARM support remained closed (until 2017) which is why the darwin-on-arm [2] project existed. But I'm assuming that the OP means that the ARM64 code was recently open-sourced in the XNU sources[3] making a possible open-source ARM port much simpler. I still find it quite interesting to see some regained attempts in emulating iOS; with Corellium being the furthest at doing this.

[1] (https://opensource.apple.com)

[2] (https://github.com/darwin-on-arm/xnu)

[3] (https://github.com/apple/darwin-xnu/search?p=5&q=ARM64&unsco...)

Well Zircon (Fuchsia's kernel) doesn't have any Rust code inside of it; it's C++. Parts of rust code used in Fuchsia can be found in the Garnet layer and it is just one of the languages that can interface with the OS via the FIDL (Fuchsia Interface Definition Language) [0][1]. An example of this is a tool written in Rust that communicates with parts of the bluetooth stack[2]. The network stack is also using it and is written in Go. [3]

[0] https://github.com/fuchsia-mirror/zircon/tree/master/system/...

[1] https://github.com/fuchsia-mirror/zircon/blob/master/docs/fi...

[2] https://github.com/fuchsia-mirror/garnet/tree/master/bin/blu...

[3] https://github.com/fuchsia-mirror/garnet/tree/master/go/src/...

A big issue with Haiku is that there really isn’t a modern web browser available right now.

The web browsers available to Haiku are all based on a recent version of WebKit (As of now we have merged commits from upstream dating from 2018), the same engine in Safari and it also allowed QtWebKit-based apps to run, previously Otto browser and Qupzilla until they migrated to QtWebEngine (based on the Blink engine which we don't have yet). So to me, that seems to be modern for a web browser that has HTML5 and can also play YouTube videos.

Also, I have just replied to your comment on a recent 64 bit Haiku nightly in WebPositive.

Well by not introducing some sort of package manager would make Haiku even less functional. How would you manage all of the dependencies that LibreOffice requires to even run? (Especially updating Qt and WebKit), let alone update the OS itself which BeOS didn't have any of this. I'm pretty sure that nearly every modern OS out there has some sort of package manager.

So I would say that by introducing this package manager has actually helped the project gain many usable applications which Haiku previously didn't have for some time.

'But is it possible to run a successful social site without that?'

Yes. Snapchat pretty much has been successful in operating with a private API and banning bots and users who use third party apps or tweaks to access its service (They actually have a DRM vendor to do this for them).

But I find it very interesting how long they can fortify their API from external parties whilst competing with other social media companies who support third-party devs.

update: it's back up now

The Casper API is the only one that works with the latest Snapchat API changes, but it is a paid service. https://developers.casper.io

edit: Specifically to storage, the Moore's Law equivalent is Kryder's Law, named after Mark Kryder. https://en.wikipedia.org/wiki/Mark_Kryder

Also within that timespan, 1.2MB of magnetic film vs 8GB MircoSD card (upto 128GB on a Pi Zero?) That's Moore's Law in action!

Right now there is!: https://github.com/apple/swift Also, the dependencies to build swift looks fine to build it on other architectures. I'll try to build it for the Raspberry Pi 2 to see.

The Swift port for Linux seems to only support x86-64 for now. https://swift.org/blog/swift-linux-port/ I would like to see how swift could run on Linux ARM devices (Raspberry Pi 2/Beagleboard/etc) and other platforms; given that the runtime is already on iOS devices. Kudos to Apple for open-sourcing Swift.

Agreed. It is the Cocoa Frameworks that are actually the closed source components in all of Apple powered OS'es. Despite the articles' inaccuracies, it would still be very interesting to see Swift being used in other platforms for both server-side activities and in mobile apps.

Seems there is another terminal emulator for Atom called Termrk. https://github.com/romgrk/termrk Both Term2 and Termrk still work on the latest Atom build.