(Chicken) Scheme.
Schemes have one of the best and most interactive interpreters Is general purpose, allows functional, procedural and OO programming, small disk size and compilable to native executables, Throughout documented and supplemented by years of research, simple setup.
It also is CGI compatible, if necessary.
I run debian on an x13s. I would not recommend it if you are an average tux member.
My recommendation would be to wait for the first devices from manufactures like tuxedo and the snapdragon elite x. And every device may have its own quirks, so wait for reviews.
It was a hard time. I daily drive it but it still remains unpolished.
A beginner linux friend of mine had an apple air m1. He ran linux on it but decided to ditch it for a framework. So i assume milage depends on your capabilities. I wouldn’t go that route and instead opted one and a half years ago for that lenovo device.
It has the best chassis I ever owned but the usability is limited. E.g.: Since Kernel 6.8 I now have to issue su -c “echo start > /some/module/thingy/mode” after each start to get external monitor, sound and battery working. Had to manually research this in IRC logs.
My two cents.
Because the trailer is more intense then any thriller ever.
Idk, I think this game already had a grid base inventory: https://de.m.wikipedia.org/wiki/Das_Schwarze_Auge:_Die_Nordland-Trilogie
April 1992.
Hehe. You came from a different direction. My main point is that reading, thinking and contributing in Swift is more familiar with the majority of developers. Currently.
Swift usage is largely isolated to Apple’s ecosystem, which doesn’t have a ton of overlap with the open-source ecosystem.
I agree that the usage is isolated and it is not represented in the FOSS community. And I am not an advocate for doing so. Though it is compatible and if it is a possible alternative it can be considered. If you compare it to other Syntax it is reading very easily and you can pick it up in 20 Minutes. They could even require to explicilty use type annotations to further aid accessibility for possible contributors or audits.
… creating libraries which can be called from virtually any other language, like you can with C and C++. Which means you’re not locked into the Rust/Apple/whatever ecosystem …
Let’s agree that a lock-in should not be dependend on the implementation language. There are other implications on the build which may arise. I am neither familiar with rust nor Swift. Comparing implications for building and linking can’t be compared by me on a professional level.
I further - without research - call out that Rust comes with implications on either library implementation or linkable procedures for an author in order to link to it. Neglecting thinks like nested interop between host/implementation language here.
But even if Rust was the most overhyped garbage, it would still be garbage that people are familiar with. ¯\_(ツ)_/¯
Two things: Every developer I have met in person whishes to get some project in Rust. No one has seriously started pushing or even learned it thoroughly. Second point: I didn’t called it garbage! The language as it is awesome. I don’t like its readability and its packaging.
When I read Rust sources it isn’t fluent in my inner mind. Sure it is due to familiarity but I would also argue that the over-expressiveness kills reading speed as well. Though that should be inspected by more objective and competent people though.
Barrier to contribute in Swift is wwwaaaaayyyy lower then Rust.
We once ported and Swift App to Kotlin by copy+pasting. It was one day of work.
Rust - imo - is overhyped. It has its niches. But to me it is not the swiss army knife. Swift has better expressiveness then Rust.
You need to write “I agree on the terms of service, rent agreement and privacy policy of any electric vehicle manufacture” in order for me to elaborate on the topic, please.
The most important thing about terminal multiplexers is that you have to atart them with the terminal command.
e.g. yourterminal --startcommand=tmux.
deleted by creator
vim is more then simple file editing.
:global, %s/, etc. which form text manipulation language (from editor ed, I guess)args & argsdo (multi-file editing)ctrl_X completion modesromainl (awesome community member)vim for one-time tasks at work. When people are proposing to script something, I open buffers, normalize the data and filter the results. I think in vim and I would very, very much recommend it, if you work with data or are a dev.
I can’t honestly recall or put my finger on it what I did wrong.
Choose fedora because it used my laptop subwoofer and wasn’t a rolling release. I remember each time (x2) reading about how to update the distro and each time my system was completely borked. I went to debian, read upon alsa, made my subwoofer work with a homegrown script and never looked back.
To this day I am wondering if people recommending redhat are trolls or paid.
Never have I ever successfully updated a fedora system. It was always a reinstall.
Graphics driver for sc8280xp are already a thing. There are more issues in convenience daily driving linux, currently. From the top of my head:
I suspect that these issues are common between their ARM chips and will be addressed for both chips almost simultaneously. But I have no real idea on kernel development. And their documentation is only shared with linaro so one can only guess.
If you run qemu from CLI you get a window which grabs keyboard and mouse automatically. Ctrl+Alt+G (from the top of my head) releases the input devices so you can again navigate the host. The window is otherwise a default window for you display server.
I find qemu from CLI way more transparent then these GUI-Applications since each vm is a readable, single script. So I recommend this.
Regarding installation on iMac bare metal: If the kernel supporta virtualization you can expect to work flawlessly. If you have a dedicated graphics card you can only pass this (as well as dedicated devices like hdd’s) if you main board supports IOMMU.
If it does all you need is the qemu man page to setup your vm.
Why I prefer a qemu script to any GUI alternative:
The entire script for passing RAM, GPU and a HDD is about 10 lines max. A default vm with tcg-emulation e.g. via libvirt etc. can pass 50 lines of xml easily.
I recommend giving it a try. My workflow is: Place the install script in some directory. The default run script is placed in my ~/.bin/ You can combine these scripts but I find it way simpler to separate them (you would need more elaborate options mounting devices).
That’s beyond my experience but I would say functional languages can perform similiarly.
I suppose - and honestly do not know if - aggregation is done via synchronization into some persistance unit.
Therefore I would eypect that a functional language like Elixir, Lisp etc. would outperform a language with manual memory management in terms of maintainability.
Depending on the capabilties of packing structs into close memory or traceability and elaboration of compiler it may outperform single or multi-threaded.
Though outperforming recent JREs may be hard, since they may trace hot paths. Default configuration Java vs. a proficient developer of a functional language I assume that latter at least go even.
But I can’t judge. Even on the repository of said program I did not even bother to look at the contents of the gradle.build or Dockerfile to be honest.
I do think that maintainability of functional languages, when only the common denominator between any functional language is used, is better to spaghetti Java source code. But that’s another issue, right?
// edit: Spaghetti Source Code is a good thing in my opinion. And sincr I did not adsress your question directly: A proficent developer is more likely to write faster Java then functional code, since Java is just a layer above C with one of the best compilers there is. Functional languages require carrying some non-neglectable knowledge of the compiler to make use of the fastest paths through the code. On the other hand Java is just ALGOL-Syntax and therefore imperative; Which translates more easier into *.asm.
// edit2: Synchronization into some db isn’t depending on the nature of the language but there may be overhead where some concepts of languages simply perform better. So I would expect that transitions from some interpreted language is slower then compiled languages. Note that even though Java belongs to the former it is conceptually compatible with the latter. I’m out. You called me out. I’m a still a newbie. Had to append so much.
There is Sublink but it’s written in Java, I don’t think I want to deal with Java’s runtime environment.
Don’t hate Java just for the sake of it. According to the repository they ship a Dockerfile and use gradle to build it. Everything should be abstracted for you.
When comparing environments for a program between Java and Python you should probably prefer Java’s. Years of experience and build from the ground up for enterprise deployment. Python module system is hacked together. It ain’t even be fair for python to compare itself in this regard.
Also this project is spot-on within Java’s main territory. It makes absolutely sense to me to use Java for such a program.
Plus monitoring/maintaining a Java application is way better then any python program.
Modularity of software ranked way too low.
Adding a terminal multiplexer. Now I understand why UNIX is an IDE.
It is bearable but feature complete. Every month linaro and the community add functionality. The most recent things include a custom power-domain mapper implementation and apparently camera support.
If you are running wayland you can simply install any os and its working oob.
The laptops weight and heat production is awesome. Very practical. Also the body is exceptional sturdy and worth mentioning (even in comparsion to a T14, e.g.).
But:
I followed almost all patches on the lkml. It appears to me that the upcoming chip can benefit from the sc8280xp hugely. It sufficies for my use cases but I promised myself a little better, yet.
Even if, we are talking about the Linux kernel. Our entire ecosystem builds upon C. People choosing C for new projects because it is the common denominator.
If Rust should be adopted in the kernel faster, patches should be send which comment how each line addresses issues of memory management solved and elaborations for rust specific patterns unfamiliar to a C dev.
Lurkers will pick up Rust that way as well.
Each Rust dev had to pick it up and therefore should be able to enable other - probably more experienced - Linux kernel hacker to provide reviewable patches.
It shouldn’t be the other way around, else you are just stepping on the efforts the other human provided to that project.