/tech/ - Technology

Technology & Computing


New Reply[×]
Name
Sage
Subject
Message
Files Max 5 files32MB total
Tegaki
Password
Captcha*Select the solid/filled icons
[New Reply]


systemd.png
[Hide] (1.1MB, 1600x900)
linuslooksalittleupset.jpg
[Hide] (16.7KB, 900x506)
Ever since I switched from systemd to sysvinit because of >>18176, I find myself questioning all these nerd turf wars I explicitly have ignored.
My normal daily setup:
- systemd
- X11 (gnome)
- Pulseaudio
- Vim
- Debian
Now I find myself wondering about OpenRC, Wayland, Alsa, emacs, LUKS, Trisquel, TailOS[, and GNU Hurd]. Which of these in your experiences have been worthwhile? What's the most privacy respecting setup?
consider Xlibre instead of Wayland
Replies: >>18394
62cab8657e4e2609048a023341299e8a341620b52dd55cfb4505594ba0c66974.jpg
[Hide] (770.4KB, 1400x1843)
>>18389 (OP) 
<gnome
Utter shit if you're not an iToddler.
>Wayland
Globohomo Freedesktop shit, basically the systemd of display servers. Try Xlibre as the other anon says.
<Vim
>emacs
Pic says everything you need to know.
>LUKS
Encrypting your drives is good.
>GNU Hurd
Will be usable in 20 years.
c6c8dc4c33d51688a1437cd2759251d9106cc08abc0e8fb9a66268905cd5b4b3.jpg
[Hide] (32.3KB, 600x315)
>>18389 (OP) 
>systemd / OpenRC / runit / ...
I don't use systemd because the developers are arrogant asshats. I never entrust arrogant people with critical components.
I used runit before on Devuan, now shepherd on Guix. runit is fine for simple setups but too limited for more complex dependency graphs. shepherd I haven't grokked yet but it does too much IMO. For some time it had a severe memory leak which led to every other process getting OOM-killed (including sshd) since you can't kill PID 1.
>X11 / Wayland
I still use X11. I don't use Gnome, only occasionally interacting with it on someone else's computer.
I don't know if I have ever used Wayland.
Honestly I don't give a shit about whichever protocol is used for drawing pixels, give me a plain framebuffer for all I care.
>ALSA / Pulseaudio / Pipewire
As I understand: ALSA is part of the Linux kernel and cannot directly be shared by multiple processes at the same time.
Pulseaudio is one project which remedies this, but because it's written by the arrogant asshat Pottering it was crap and had insane shitty defaults like 100ms buffering.
It is better nowadays, though I think most distros now use Pipewire with a Pulseaudio compatibility layer. Not something I care about anyway, as long as it plays audio with reasonable latency.
>GNU Hurd
Overengineered kernel used by no-one. Linux was meant to be a temporary substitute, but it's basically permanent since so many corporations put their weight behind Linux + hardware interfaces are crazy complex nowadays, so writing drivers takes a heroic amount of effort even if you have access to complete documentation. (just look at the typical hobby OSDev project: the majority are 32-bit Unix clones based on ancient tutorials using even more ancient, obsolete hardware).
>Vim / NeoVim / Emacs
I use NeoVim because I'm familiar with it and it has okay-ish LSP support. I work most efficiently with the shell and I find that (N)Vim integrates well with my workflow.
Again, not something I really care about. I've taken a stab at writing my own text editor a few times but abandoned it because I currently don't have any ideas that would be a meaningful improvement.
>LUKS
I don't currently use it, but I do plan on using LUKS with AES-XTS in the future.
I would prefer OPAL or some other form of on-disk encryption but somehow that still isn't a very common feature everywhere it seems. The advantage of on-disk encryption is that it is always-on, which in turns makes "erasing" as simple and fast as just generating a new key, so it isn't something you can forget to set up like I do.

>What's the most privacy respecting setup?
The one you control.
>>18391
It's probably worth messing around with both instead of just taking other peoples' word for it. Unlike init systems, you can easily switch between X11 window managers and wayland compositors on the same system through startx scripts and display managers, so you actually can just flip between the two and compare the state of them. You can't do that with Xorg and Xlibre though, as both want to be the one X11 implementation on your system.
It also helps that Xlibre's communities takes the time to make a bunch of third-party repositories for distros which don't carry it yet, although the quality of those varies. Void's main one, for example, doesn't pull in nearly as many expected default package as the distro's base xorg package does, but Devuan's works swimmingly as long as you've enabled backports.
>>18389 (OP) 
It seems like the conflict between vim and emacs is mostly over, as people care about other stuff. Still, it seems to be that it had two parts:
>controls
Vim is definitely better than emacs by default, because it's a modal editor so you don't need to rely on modifier keys even for the most basic of basic operations (other than typing text), and most key presses are named to work as abbreviations, so you don't need to rack your brain to remember that you can replace a word by pressing c then w, as that is short for change word. But then emacs can be turned into a modal editor, the evil package copies vim's behaviour rather well. I've been using xah-fly-keys for a few weeks, and it's not as straightforward as vim's at first, but I like it so far. Still, back in the 1990s and 2000s there weren't all these nice packages that you could download, so most people just tried out both emacs and vim, preferred one over the other, and clashed over this with others.
>the programs themselves
Vi started life as a program built over ed, and you should really look up that and even try it out to see what it's like to edit text via the command line when you really only have access to a single line. Although it should be noted that back then most people would have used teletypewriters, so you could just print the whole text once and use that hard copy as a reference. Still, it was made at a time of limited resources and ”primitive” input-output devices, so the program had to be simple, fast and efficient.

Emacs is ultimately meant to be an interface to a computer, as it's written in LISP by people who were fucking around with expensive LISP machines back in the 80s. The interface might be text based, but calling it a text editor is like referring to a laptop as a typewriter: sure, you can type out whatever you want to write, and with a printer you can even commit it to paper, but if you really just need to put a few letters on a piece of paper, then a typewriter is a much simpler solution. And this is why emacs comes with a lot of ”bloat” such as a web browser and a bunch of games even in a default installation: it's pretty much the user facing half of an operating system that for some dog forsaken reason is called a text editor by the very people who develop it. It can be a great thing if you get into it, but if you only need to edit a random config file on a computer once in a blue moon then it's definitely overkill.
Replies: >>18396
>>18395
Sometimes I look at the GNU project's design decisions and wonder if Stallman shouldn't have instead tried to make another Lisp-centric OS instead of a janky Unix implementation without a kernel.
Replies: >>18397 >>18398
>>18396
https://stallman.org/stallman-computing.html
>I never used Unix (not even for a minute) until after I decided to develop a free replacement for it (the GNU system). I chose that design to follow because it was portable and seemed fairly clean. I was never a fan of Unix; I had some criticisms of it too. But it was ok overall as a model. 
Part of the problem is that they wanted to be really bleeding edge with Hrud's microkernel. But an other problem is that LISP back in the 80s and 90s was confined to LISP machines because you really couldn't run it efficiently on most architectures, so they so that's why emacs is only half of an operating system. It makes sense on paper: make a FOSS OS that is the rough copy a popular OS, and then you can just run emacs on top of that and feel like you are in MIT's artificial intelligence lab, or write all the programs required to for a more traditional UI and get more people to use it that way. In practice it really didn't work out that well for them.
Replies: >>18399
>>18396
until there are kernel independent drivers without licensing issues, making a new kernel that people will actually use will stay virtually impossible
Replies: >>18399
>>18397
It least we got GCC and a bunch of other software out of it, even if a lot of it has its issues.
>>18398
IIRC the Hurd has benefited a lot from exactly that lately thanks to rump kernels, but I haven't looked much into the specifics yet.
Replies: >>18401
>>18399
>rump kernels
not enough people even know this exists
Ccpenguin,_the_ancestor_of_Tux.jpg
[Hide] (11.1KB, 267x372)
When will linutards stop obsessing over inconsequential under-the-hood software and instead start making programs that actual human beings want to use?
I would personally love it if the turbo autists concentrated their efforts towards a new simplified and lightweight GUI toolkit that isn't ((( Gtk ))) or ((( Qt )))
Terry_where_computers_went_wrong.webm
[Hide] (1.4MB, 1280x720, 00:26)
>>18434
>actual human beings want to use
Niggers, women, jews, and faggots aren't actual human beings.
>>18434
>stop obsessing over inconsequential under-the-hood software
>start obsessing over inconsequential under-the-hood software THAT I PERSONALLY CARE ABOUT
GTK and Qt work just fine. As for the actual user-facing software, be the change you want to see. No one owes you anything.
Replies: >>18444
>>18434
It's better this way let the goypenguins enjoy their little toys, kikechads will keep winning.
Replies: >>18444
>>18434
>under-the-hood
>inconsequential
this is your brain on microcuck
Replies: >>18444
>>18434
you need the shit under the hood to make everything else work
Replies: >>18444
What about the hardware backdoors?
What can you do about that?
>>18436
>GTK and Qt work just fine
Both suffer from severe instability and bloat, the minute you stop updating/rewriting a program to keep up with the library changes it just stops working. This is in stark contrast to the win32 API which is lightweight and has worked more or less flawlessly for 30 years without changes.
>No one owes you anything.
Linux devs will say this shit then turn around and bitch about Linux adoption being low and the "year of the Linux desktop" failing to materialize... And also bitch about FOSS lacking maintainers and being taken over by turbo autistic trannies, when said FOSS has always remained hostile to anyone but said turbo autistic trannies.

>>18437
>kikechads will keep winning.
I'm guessing that's kikechads as in microkike (Microsoft)... No, they're not winning, and haven't been winning for close to a decade now. The average Windows user is more distraught with the OS today than ever before because of MS' incompetence. MS is practically handing its users to Linux on a silver platter, yet Linux refuses those users because it would rather focus on benign pieces of software instead, rather than put in the minimal effort required to make the OS more appealing to users migrating from Windows.

>>18438
>this is your brain on microcuck
I haven't booted into Windows in years, and I have more or less built my career on Linux... You're like the libre version of the Macfag who can't fathom anyone hating his favorite OS.

>>18442
>you need the shit under the hood to make everything else work
The "shit under the hood" already in place at the moment, whether it's X11/Wayland, ALSA/Pulseaudio, systemd/runit/openrc, is more than serviceable. Not perfect, but serviceable.
Maybe it's time to stop trying to perfect the car engine and finally install some seats for humans to sit on, and a steering wheel.
Replies: >>18445 >>18449
>>18444
>the minute you stop updating/rewriting a program to keep up with the library changes it just stops working.
This is one thing I strongly dislike about GNU mentality: from what I hear they deliberately encourage API breakage to discourage proprietary implementations from remaining closed-source.
Of course, this increases churn massively for everyone involved and wastes time that could be spent much more productively.
Apparently LLVM was originally intended to be integrated into GCC, but LLVM would provide a quasi-stable interface and hence was rejected. We all know the final result.

And of course, encouraging constant breakage to deliberately frustrate developers of course attracts people who enjoy frustrating other people.

Linus has the right mentality with keeping the syscall layer rock-stable. I'm convinced it is a major reason for Linux' success.
(Most other OSes keep API stability at a higher layer, usually libc or similar, but Linux is just a kernel).
If GTK or Qt were good enough, apps wouldn't be written with ultra bloat like Electron.
Replies: >>18449 >>18464
__original_drawn_by_yajirushi_chanoma__48307245a3796c8816aa053fe259ca6c.png
[Hide] (1.4MB, 1100x800)
>encouraging constant breakage to deliberately frustrate developers of course attracts people who enjoy frustrating other people
absolute trvth nvke
Replies: >>18448
k87t5aiis5p31.jpg
[Hide] (822.5KB, 3024x4032)
>>18447
↑ is quoting ↓
>>18445
AMHIG.jpg
[Hide] (165.2KB, 807x1024)
>>18444 (czech'd)
>Qt
Lumping Qt in with GTK is unfair, especially since Qt is a reasonably sane crossplatform tool used without issue in so many Windows/Mac/Android/iOS apps.
>the minute you stop updating/rewriting a program to keep up with the library changes it just stops working
I don't think that's the toolkit's fault, but like >>18445 sez the Linux kernel's (intentionally!) unstable ABI. Other OSs, even other freetard OSs (BSD, Plan 9, Haiku, etc.) do not have this problem.
>Maybe it's time to stop trying to perfect the car engine and finally install some seats for humans to sit on, and a steering wheel.
I still remember when OSuX happened with its crappy browser/spatial Finder, and some of the people behind the "classic" Mac Finder were brought into the Nautilus project with the goal of redesigning Gnome around a rigorous HIG. They did good work, but it didn't even last until 3.0 before CADT reasserted itself.

Hopefully somebody out there still cares about good design, like maybe helloSystem.

>>18446
The excuse given by Electron shitters isn't "my platform's native toolkit is too hard", but "crossplatform dev is too hard", most of them are unaware that Qt and several other sane toolkits support not only every desktop OS but also mobile and web with a single deployment.

The actual motive for Electron devs is baby duck syndrome from subhumans who only know webdev and refuse to learn anything else.  Even this excuse is lame, since Electron has other alpha-quality flaws so unjustifiable the devs lied they intended to fix them in its first year, like ignoring the OS's native browser to bundle its own copy of Chromium, and ignoring other running Electron apps even with the same bundled Chromium/Node to gobble even moar RAM.
Replies: >>18464
>sez the Linux kernel's (intentionally!) unstable ABI
No, the kernel does have a stable syscall ABI/API. It is userland on top which tends to break far too often.
Unless you're talking about drivers specifically. Linux mitigates this by forcing every driver to be upstreamed, but not every vendor does this and embedded platforms tend to be stuck on old kernels as a consequence.
Upstreaming everything is also why the kernel is now so huge not even Linus has a full overview of the kernel, let alone any new developers.
But kernel drivers shouldn't directly affect userland in most cases anyway, main exception I can think of is GPUs.
Replies: >>18452 >>18464
>>18451
My understanding might be mistaken, but I'm under the impression the only stable ABI in Linux is kernelspace:userspace, whereas kernelspace:kernelspace is INTENTIONALLY unstable, and userspace:userspace is (far from always but often enough to be annoying) cause problems UNINTENTIIONALLY unstable.

For instance, glibc is SUPPOSED TO BE stable at the ABI level, and ABI breakages are (at least officially) WILLFIX bugs to be reported.
Replies: >>18453 >>18455
>>18452
>My understanding might be mistaken, but I'm under the impression the only stable ABI in Linux is kernelspace:userspace, whereas kernelspace:kernelspace is INTENTIONALLY unstable, and userspace:userspace is (far from always but often enough to be annoying) cause problems UNINTENTIIONALLY unstable.
Yes, that is accurate
>For instance, glibc is SUPPOSED TO BE stable at the ABI level, and ABI breakages are (at least officially) WILLFIX bugs to be reported.
Yes, though they do this through symbol versioning which:
- you have no control over during compilation (AFAIK), with the only solution being to target an older version of the library.
- leads to duplicate implementations of functions, which each implementation behaving subtly differently.
- is why you can't just take a program compiled for one distro and plop it on another even though they might both use glibc.
Replies: >>18454
>>18453
I believe another problem stems from packagers (or maybe devs?) habitually building EXCLUSIVELY against newer versions, making backcompat impossible on even slightly older OSs.

Whereas on Windows/Mac/BSD/etc., it's conventional for devs to link against frameworks for MULTIPLE older versions of the OS, resulting in microscopically larger binaries that will run on far more OSs.
Replies: >>18455
>>18452
>>18454
read the faq
you don't have to use caps lock for emphasis
Replies: >>18456
cruise-control-on-steering-wheelcruise-260nw-512787763-crop.jpg
[Hide] (27.3KB, 390x259)
>>18455
Sorry, I just wanted cool. The only things I think are missing from h8ch are ''bold italic'' and [spoiler]nested spoilers[/spoiler].
>>18445
>I hear they deliberately encourage API breakage to discourage proprietary implementations
While I'm yet to find solid proof of this, it sounds about right. Given the FSF and GNU project's historic hostility towards proprietary software it's absolutely plausible that they would intentionally sabotage APIs/ABIs which certain programs depend on.
Ulrich Drepper, the lead developer behind the GNU C Library, has constantly asked users in the past to recompile/rewrite software instead of fixing bugs he introduced. This exchange in particular is eye opening:
>Ulrich Drepper: programs which don't handle multiple addresses are simply broken and must be fixed anyway.  Stop defending broken code.
<But your implementation violates RFC2553
>Stop reopening the bug.  If you want explanations pay somebody.
From https://sourceware.org/bugzilla/show_bug.cgi?id=4980

>>18446
>If GTK or Qt were good enough, apps wouldn't be written with ultra bloat like Electron.
True. I've downloaded many pre-compiled Gtk, Qt, and Electron apps over the years, and surprisingly only the Electron ones are still working properly to this day. Crazy how the two main GUI libraries on Linux failed so spectactularly at their one job that the only practical alternative became shipping a fucking web browser instead.

>>18449
>Qt is a reasonably sane cross platform tool 
Nah that would be Chromium/Electron, sadly.
Qt breaks backward compatibility between minor versions, especially in the 5.x series, by constantly changing APIs. I've personally had the misfortune of using a handful of programs that had to be recompiled with each new Qt 5.x release, or else they would stop working. Not my idea of sane.
A common workaround for an unstable library like Qt is manually compiling it as a static library and linking that into your program, so the resulting executable has no dependency on the system Qt version whatever that may be. This is, of course, easier said than done, because Qt is so massive and complex that compiling it is a nightmare. After many tries and countless compilation errors, I once managed to compile a single version of Qt (can't recall if it was 5.8 or 5.9) while every other version failed to compile. The compilation finished after almost an hour and used half a dozen gigabytes, but the example programs worked, which was great. Unfortunately the compiled library failed to link to any real life program, likely because of the aforementioned APIs.
Mind you that I had no issue compiling libraries like X11, SDL, and GLU in the very same environment. I even managed to bootstrap several GCC versions from scratch without issue. You know something is seriously wrong when a GUI library is harder to compile than the fucking compiler.

>>18451
>the kernel does have a stable syscall ABI/API. It is userland on top which tends to break far too often.
And the broken userland in question is mostly GLIBC (GNU C Library), the main culprit for instability on Linux and the reason why you can't share executables between distros.
Other libraries breaking their ABIs are only following GLIBC's footsteps. When the most basic and most crucial library in the whole system has no stable ABI, why would anyone bother?
Replies: >>18466 >>18467
Black_wildebeest,_or_white-tailed_gnu,_Connochaetes_gnou_at_Krugersdorp_Game_Reserve,_Gauteng,_South_Africa_(27410161911).jpg
[Hide] (86.1KB, 500x695)
Since this is a thread about controversies, I might as well post about GNU's crown jewel; GLIBC. I've been keeping tabs on GLIBC's controversies for a while now and would love to share them ITT... If I missed anything feel free to point it out.

GLIBC 2.38 removes libcrypt; breaks sudo, vim, 20+ other packages

*	Official GLIBC 2.38 release notes
	Building libcrypt is disabled by default
	libcrypt may be removed completely in future Glibc releases
	https://sourceware.org/glibc/wiki/Release/2.38#Building_libcrypt_is_disabled_by_default
*	GLIBC 2.38 blocked on Ubuntu, 23 packages broken
	https://web.archive.org/web/20230829130711/https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html
*	GLIBC breaks sudo on Void Linux
	https://voidlinux.org/news/2024/01/glibc-xcrypt.html
*	Other bug reports
	https://forums.gentoo.org/viewtopic-p-8672853.html
	https://github.com/orgs/Homebrew/discussions/3570
	https://bbs.archlinux.org/viewtopic.php?id=274160
	https://github.com/landley/toybox/issues/450
	https://stackoverflow.com/questions/71187944/dlopen-libcrypt-so-1-cannot-open-shared-object-file-no-such-file-or-directory

GLIBC 2.36 removes DT_HASH; breaks Shovel Knight, EAC games, libstrangle

*	TL;DR version and why devs prefer Win32 over Linux
	https://blog.hiler.eu/win32-the-only-stable-abi/
*	Bug report on Sourceware (WONTFIX)
	It is up to the distributions to decide how to proceed
	There is no intent to fix this in glibc by forcing both hashes.
	https://sourceware.org/bugzilla/show_bug.cgi?id=29456
*	Valve employee: glibc not prioritizing compatibility damages Linux
	https://archive.ph/X0lMj
*	The ABI status of ELF hash tables
	The DT_HASH format is mandated by the System V ABI
	the DT_GNU_HASH format is undocumented, and there has been no deprecation campaign
	https://web.archive.org/web/20240115181049/https://lwn.net/Articles/904892/
*	Online discussions
	https://www.reddit.com/r/linux_gaming/comments/wftxkn/glibc_236_breaks_eac/
	https://www.reddit.com/r/linux/comments/wp3hr9/win32_is_the_only_stable_abi_on_linux/
	https://news.ycombinator.com/item?id=32471624&str=win32_is_the_only_stable_abi
	https://news.ycombinator.com/item?id=32545603&str=glibc_and_dt_gnu_hash

GLIBC 2.36 alters mount API; breaks LLVM, System D, QEMU

*	Official release notes
	<linux/mount.h> and <sys/mount.h> headers are no longer directly compatible
	Applications need to be adjusted for the new updated headers
	https://web.archive.org/web/20220719035141/https://sourceware.org/glibc/wiki/Release/2.36
*	Other bug reports
	https://lore.kernel.org/all/[email protected]/T/
	https://reviews.llvm.org/D129471
	https://github.com/llvm/llvm-project/issues/56421

GLIBC 2.19 alters jmp_buf size, breaks 500+ packages

*	Announcement on LWN
	https://archive.ph/M1KUB
*	Online discussions
	https://news.ycombinator.com/item?id=30712172&str=glibc_s390_abi_break
	https://lobste.rs/s/btqpqv/glibc_s390_abi_break_2014

Tabular data for each GLIBC release

*	Official GLIBC changelog
	https://sourceware.org/glibc/wiki/Glibc%20Timeline
*	List of added and removed GLIBC symbols
	https://archive.ph/XHHjh
*	Linux kernel and GLIBC API changes
	https://man7.org/tlpi/api_changes/

Pro GLIBC propaganda

*	glibc and DT_GNU_HASH
	I wish that people can stop defamation to glibc.
	DT_HASH has been mostly eliminated from Linux distributions
	https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash
*	How GLIBC handles backward compatibility
	to run on an old glibc [...] have a copy of that old glibc and its headers
	install an older operating system that has the version of glibc you want
	https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility
Replies: >>18466
>>18464
Maybe the final solution to the GUI question is to convince normalfag that ncurses programs running in terminal emulators are better. I mean, I genuinely believe so, but many normalfags are scared of letters and numbers, even if the program has okayish mouse support.
>>18465
Suckless starts the list of things that suck with glib:
https://suckless.org/sucks/
>glib - implements C++ STL on top of C (because C++ sucks so much, let's reinvent it!), adding lots of useless data types for "portability" and "readability" reasons. even worse, it is not possible to write robust applications using glib, since it aborts in out-of-memory situations. glib usage is required to write gtk+ and gnome applications, but is also used when common functionality is needed (e.g. hashlists, base64 decoder, etc). it is not suited at all for static linking due to its huge size and the authors explicitly state that "static linking is not supported".
<Alternatives: libmowgli, libulz, BSD queue.h/tree.h macros.
Replies: >>18468
>>18464
>Qt breaks backward compatibility
>compiling it is a nightmare
>no issue compiling other libraries
When some important aspect of open source software is failing, there comes a point in time when active sabotage should be suspected.
My mind first goes to Microsoft (with the Windows APIs competing in this case), especially since they already have a history with sabotaging Linux.
Replies: >>18469
>>18466
>https://suckless.org/sucks/
Why exactly are gcc and clang coded in c++?
>>18467
And I'll ask the follow-up myself.
If Microsoft is sabotaging cross platform UI, then why would Electron not be sabotaged?
The answer is that they are already working on it.
Microsoft uses "embrace, extend, extinguish", and is now "embracing" in this area.
One example is Edge, which is also based on Chromium (the engine used by Electron), and is further focusing on this broader technology by using React Native for core components of the Windows 11 UI.
It's only a matter of time before they introduce changes that are prohibitively difficult to keep up with, and will make it a horrible experience for users and developers.
Replies: >>18474
>>18469
Another important example of MS embracing Chromium is VS Code.

Also, they might introduce changes to have more influence in Linux, for example by depending on systemd.
This way it does "work on Linux", but only if you help to give them more power, which they will inevitably abuse further on.
tl;dr for people who don't feel like wading through a book's worth of wiki pages and imageboard posts

A. glibc has maintained ABI stability for decades, sure every now and then there's a bug, but they've maintained ABI stability

B. ABI stability doesn't mean that your program will continue to work if you rely on undocumented implementation details, 

C. jeets have failed at B since before the dawn of the electronic computer, and for some reason game devs chose the hash format used for symbol lookup as the hill to die on, something a video game has no reason to care about
[New Reply]
37 replies | 11 files
Connecting...
Show Post Actions

Actions:

Captcha:

Select the solid/filled icons
- news - rules - faq -
jschan 1.7.3