Well deserved. Though, I have problems in "discovering" apps for a particular purpose. It would have helped if there was a vote-based curated app categories section.
My current strategy is googling for "[category (e.g. 2FA or note-taking)] + reddit + open-source" then opening up each suggestion's git source and manually look for things like tech stack or project stars or number of contributors.
On software side, RPi (or intel N100 for that matter) is the winner but take a look at RK3588 datasheet [1] and tell me of an Arm or x86 SBC that tops what it offers. It even comes with a NPU lol
The rk3566 used in Rock3A is a poor 4-core Cortex-A55 chip, it can't even beat the RPi 4. But when it comes to the 4xA76 + 4xA55 in the rk3588/Rock5, they can't be compared, not to mention the 8k60 video codec and NPU support in the 3588.
What's wrong with systemd? From the user's perspective, it streamlines managing services in a uniform way. It's good that journalctl, systemctl, systemd-analyze work on pretty much every desktop and server OS.
The systemctl start/stop/status is no problem and better than init scripts (everything is better than init scripts). The issues stem from the complexity of the system and the amount that each module wants you to use it with other modules.
A simple version of the same is runit. Side by side, you can see the complexity differs by orders of magnitude.
I've used it for as long as it was introduced in Arch back in the days. The system update was an... experience then but that is the only bad thing I can think of.
I'm now using systemd, Wayland, Pipewire and all that in my NixOS installation and can't understand the hate. People should maybe just let go...
They should write an OS that is "so good" that people start talking about it as much as the options we have now, then people actually start using it on their servers (replacing GNU/Linux), then on their desktops. So good that companies like Google and Apple would consider making their next OSs or userland utilities in Rust.
It already happened for some programs like Alacritty, ripgrep but failed to do so in some other domains like user-space window managers.
The common argument against it is complexity and learning curve (compared to C).
Perhaps I'm not the one who should voice his opinion on this but anyway, I don't like _two_ languages in Linux kernel especially one that increases compile time and imposes heavy storage requirement on the development machine. If they want to add it, they should consider migrating everything to it IMO.
> They should write an OS that is "so good" that people start talking about it as much as the options we have now, then people actually start using it
Is the proposal here to replicate the 30 million lines of code of Linux? Anything short of that is going to have massive adoption problems, much like Linux did in the past, much like FreeBSD/Illumos/etc do now, due to the lack of drivers. It took so long, and devices still don't properly support Linux; there is no way another free and open source system will take off like Linux did, ever again.
> failed to do so in some other domains like user-space window managers
Do things like Way Cooler and COSMIC not count?
I have seen Way Cooler mentioned as being used a couple times, and COSMIC gets regular coverage for its development progress.
exposing billions of people to security vulnerabilities by preventing Rust from being used in Rust due to compile times or storage requirements of developers is morally questionable
What modern scheme is best to use for these "the little x'er" book series? Some of them suggest their dialect (like learner suggests Racket I think), but what about others?
In short, what scheme is the most practical and useful nowadays?
Here is the result of my research so far, in order of preference according to the above requirements:
Guile: most active community, GNU glue language, Guix
Chicken: most pragmatic one with a package manager but older
Chez: most performant one, less active community and libraries
I don't know what is the best Scheme implementation, but this book has little to do with Scheme though. Pie uses S-expressions for syntax, and happens to be implemented in Racket, but you don't interact with Racket directly.
This is the last thing I'd worry about. The series isn't about teaching you a language you can use later in industry. It's about teaching you higher-level concepts you can take with you to any languages you may encounter in the future.
A book like this doesn’t need to be “practical” and “useful” - I don’t think, say, the shortage of libraries for Chez Scheme is going to hamstring you in anyway.
Guile probably has the best Emacs integration through Geiser. While you don't really need it and you can just follow along with a terminal REPL, using something like Geiser helps keeping the experience smooth.
MIT/GNU Scheme comes with its own editor, edwin, which is a terminal-only Emacs-like. I don't know how much it complies with the various RnRSes, but I do believe it's good enough to work for the Little series.
Gauche is R7RS-small (and I believe -large up to Tangerine) compliant so it should just work. It also has fairly good Geiser support and comes with an enormous standard library, 'batteries included' as they say, though its performance is a bit lower than some of the other implementations.
Cyclone is R7RS-small compliant so it should work. It seems fairly fast and it has a package manager, but because it's fairly new I don't know how well it works with Geiser.
Loko is R6RS compliant so it should work. I believe the documentation says that it should work with Geiser using the Chez module, but I may be mistaken.
Gerbil is R7RS-small compliant (and I believe -large through Red, maybe through Tangerine?) so it should work. I believe it's also quite performant, though I haven't used it.
Kawa is R7RS-small compliant if I'm not mistaken. If so it should work for the Little series. It also has a Geiser module.
And then there are a few implementations of which I'm not entirely sure which version of the spec they comply with and how well they're supported by various editors (though I think SLIME has Scheme support, although that may only be for MIT/GNU Scheme): Gambit (I think R5RS? Gerbil is built on top of it), Bigloo (I think R6RS?), Larceny, Chibi Scheme, Biwa Scheme, S7, and IronScheme. For any of those, as long as they support post R4RS macros (so using `define-syntax' and `syntax-rules' instead of `defmacro)' they should work for the Little series without any adjustments. If they're still using `defmacro' then you'd need to translate the macro definitions from Reasoned (and later?), which isn't that hard... but if you're gonna do that you may want to read On Lisp after Seasoned.
As someone who doesn't know much about types, do SBCL type declarations provide as good type-based development experience as OCaml and Rust?
And perhaps I wouldn't get your answer, I mean is there something fundamentally inadequate in the way SBCL declares types? I think there is a phrase for it in CS theory.
> As someone who doesn't know much about types, do SBCL type declarations provide as good type-based development experience as OCaml and Rust?
First of all, op was talking about strongly typed languages. Asking are they good as statically typed ones like Rust and OCaml is raising the goal posts quite a bit.
Second of all, SBCL can indeed have a subsection of its code expressed in OCaml-like static types, see
To add to the other comment, it is also important to understand in the more interactive mode of developing in CL. You basically have the program always running, fixing bugs and adding features while it is running.
You simply don't have the problem of batch style programming where you have written a bunch of code and now you want to know if it works so you run a lot of static analysis on it beforehand because running it and getting it to the point and state that is relevant costs time.
In CL you don't end up with lots of code that has never been run. You have constantly run it during development and are much more confident about its behavior. So just having this interactive way of programming already leads to much more reliable software. It is not a replacement for static analysis or unit testing of course but another pillar to help you write more correct software.
not to be horrible or picking on you, but it is "rogue". i would have thought that most people here would have come across games featuring a "rogue 5hp hit, 8 sneak" character to be able to spell this right, but almost everyone does it wrong. ok - picky, picky me.
It's a little much to say almost everyone does it wrong. More likely, since it's something that catches your notice, you probably have a bias for noticing/remembering when it's incorrect and not noticing when it's correct. It could also just be a simple typo or an autocorrect error for any given occasion
I wish the likes of Nintendo and Sony themselves finance such efforts. I mean it's one another way to create games (IP) for your console, what possibly could be the downside of starting something similar to Github Accelerator for your platform?
Because it's well established that game developers can and will jump through whatever hoops the platform holder demands at their own expense, they don't have the leverage to be picky about the technical details when deciding which platforms to ship on. Nintendo doesn't need to create new incentives to release on the Switch when they already have the biggest incentive of all: 140+ million units sold, and a high attach rate.
At least there isn't as much hoop jumping as there used to be, since the systems have all converged on using commodity CPU and GPU architectures with at most minor embellishments.
Yeah, also whatever they would build, the other platform vendors won't choose the same thing, and it wont be the exact variant of lisp or w/e that even the few nice developers would want.
I wish vendors would be just more supportive of different llvm tool chains. Rust isn't even well supported.
Rust isn't even available on Android NDK, even though is now used on Android.
Same applies to Rust on Windows, and whatever Microsoft is doing, windows-rs isn't that great, and after what the team did with C++/WinRT I don't have high expectations.
So consoles have even less reasons to support Rust.
My current strategy is googling for "[category (e.g. 2FA or note-taking)] + reddit + open-source" then opening up each suggestion's git source and manually look for things like tech stack or project stars or number of contributors.