mid-kid

So why does nobody ever talk about Haxe in the context of an "everything" language?

I agree, this should be the case, but Gradle specifically relies on downloading prebuilt java libraries and such to build itself and anything you build with it, and sometimes these have prebuilt native code inside. Unlike buildroot and any linux distribution, there's no metadata to figure out how to build each library, and the process for them is different between each library (no standards like make, autotools and cmake), so building the gradle ecosystem from source is very tedious and difficult.

I think it's extremely useful to have more strict requirements on how programs are built, to make sure that developers don't do stupid things that makes code harder for others to compile.

The tools in question in OP should be easy to build from source and not rely on the host's architecture, to be usable on platforms like ARM and RISCV. It's clear that in the android ecosystem, people don't care, so F-Droid can't do miracles (the java/gradle ecosystem is just really bad at this), but this would not happen if the build tools had proper build recipes themselves.

By topping the leaderboard plenty of people see it and donate their IP to them. What are you gonna do, claim your own IP for yourself and go up against those behemoths? Of course you're gonna form alliances.

Early Newgrounds would like to disagree...

Unlike the UK Internet Safety Act, the GDPR is really easy to comply with for small independent websites. It was aimed at the big companies and companies unethically mining data, and it didn't do much outside of that scope.

The only HiDPI setting I toggle is Xft.dpi in ~/.Xresources This scales fonts in gtk3, and is used for the scale factor in firefox and Qt apps, and is recognized by most apps using something custom.

In my experience, too many of these curl scripts are a bootstrap for another script or tarball which gets downloaded from somewhere else, and then downloads more stuff. Looking at just the main script tells you nothing. Consider for example the rust install procedure: It downloads a binary rustup, for bootstrapping, which then does the installation procedure and embeds itself into your system, and then downloads the actual compiler, and you have no chance of verifying the whole chain, nor really knowing what it changes until after the fact. Consider also systems like `pip` which through packages like puccinialin do the same inscrutable installation procedure, when a rust-based python package needs to be compiled.

Suffice to say, it's best to avoid any of this, and do it using the package manager, or manually. I only run scripts like this on systems that I otherwise don't care about, or in throwaway containers.

We all know it's going to be friday. That's already the most quiet day where I live.

Not conservative but I used to love the meme before it was co-opted by musk, so I will occasionally use it as a "haha now you feel OLD" without thinking of its modern connotations.

I'm not sure how willing I'd be to trust a pthread library fork from a single no-name github person. The mingw-w64 project provides libwinpthread, which you can download as source from their sourceforge, or as a binary+headers from a well-known repository like msys2.

This is why I avoid aluminum laptops. Too many plugs aren't properly grounded and the tingling annoys me to no end.

GMail was still fresh at the time, and it rolled out in a similar manner, being invite-only at first. I think they didn't think about it very much, and just did the same thing.

> things like multi-touch gestures are plainly broken on X11 mode in ever DE I've tried

The main reason for this is that neither major DE has implemented multi touch gestures on X11. Not that they can't be.

There's several tools you can use for things like touchpad gestures on X11 and they work well, but aren't as nice as native integration into a DE.

How does this compare to https://www.dns0.eu/ which I've been using for years?

That's true. I find myself still saying GNU/Linux where it's relevant (e.g. when referring to the userland, or a compatible userland) but it's not as contentious as it used to be, which is a nice breath.

We've accepted it at this point, but I wonder if the religious element of GNU tools and free software in general was as contentious way back when.

There's been cases[1], of particular note, the unescape overflow one[2]. This one scathed the reputation of sudo enough to get people pushing for alternatives such as doas. The track record of vulnerabilities in general leaves a bit to be desired, even outside of memory vulns.

[1]: https://www.sudo.ws/security/advisories/

[2]: https://www.sudo.ws/security/advisories/unescape_overflow/

What are you talking about? Technology is as widespread as ever and chances to use AI for more effective surveillance and manipulation are through the roof.

> homebrew always was always somewhat equal to piracy

I can't speak for everyone but personally I find there's a moral imperative in making sure that we can actually own the devices we buy. Comments and sentiments like these needlessly devalue the work being done to achieve this, and is part of why the broader homebrew community is bitter about it.

The significant difference between Jazelle and your project is how Jazelle sits on top of a CPU that can already run a java interpreter without the instruction set extensions, said instruction set didn't implement all of java (it still required a runtime to implement the missing opcodes, in ARM), and java runtimes quickly got better optimized than doing the same thing with the instruction set.

I think building a CPU that can only do this is a really novel idea and am really interested in seeing when you eventually disclose more implementation details. My only complaint is that it isn't Lua :P

What an incredibly toxic way to view dissatisfaction with modern day hustle culture. There's an incredible amount of activities that contribute to society but aren't valued with money - only with wellbeing.

I wish I could do unpaid volunteer work and still afford live. By which I mean, I really hate that certain kinds of work are not deemed worthy enough of financial compensation, yet are still beneficial to people and society at large.

This has been my take on things forever. Power user tools tend to be made as a TUI, which is great in that it lets you work from the framebuffer and over SSH, but it really makes you wonder why we can't have the same conveniences with proper graphics.

In my experience distributions only patch GCC or modify the package building environment variables to add compiler flags. You can be certain that the compiler flags used in build systems like cmake and meson will be vanilla.

Make adds no additional compiler flags (check the output of "make -n -p"). Neither does Ninja.

Autotools is extremely conservative with compiler flags and will only really add -O2 -g, as well as include paths and defines specified by the developer.

CMake has some default compiler flags, depending on your CMAKE_BUILD_TYPE, mostly affecting optimization, and disabling asserts() with Release (-DNDEBUG). It also has some helpers for precompiled headers and link-time optimizations that enable the relevant flags.

Meson uses practically the same flags as cmake, with the exception of not passing -DNDEBUG unless the developer of the meson build really wants it to.

These are all the relevant build systems for linux packages. I'm not familiar with gn, bazel, and etc. In general, build systems dabble a bit in optimization flags, but pay no mind to hardening.

While all of these are very useful, you'll find that a lot of these are already enabled by default in many distributions of the gcc compiler. Sometimes they're embedded in the compiler itself through a patch or configure flag, and sometimes they're added through CFLAGS variables during the compilation of distribution packages. I can only really speak of gentoo, but here's a non-exhaustive list:

* -fPIE is enabled with --enable-default-pie in GCC's ./configure script

* -fstack-protector-strong is enabled with --enable-default-ssp in GCC's ./configure script

* -Wl,-z,relro is enabled with --enable-relro in Binutils' ./configure script

* -Wp,-D_FORTIFY_SOURCE=2, -fstack-clash-protection, -Wl,-z,now and -fcf-protection=full are enabled by default through patches to GCC in Gentoo.

* -Wl,--as-needed is enabled through the default LDFLAGS

For reference, here's the default compiler flags for a few other distributions. Note that these don't include GCC patches:

* Arch Linux: https://gitlab.archlinux.org/archlinux/packaging/packages/pa...

* Alpine Linux: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/d...

* Debian: It's a tiny bit more obscure, but running `dpkg-buildflags` on a fresh container returns the following: CFLAGS=-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/<myuser>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection

I generally just have a makefile that for each page does `cat header.html page.html footer.html > out/page.html`. I realize this can be considered a "static site generator" but I think simple concatenation covers most of the painpoints of writing static sites manually, without introducing intermediate formats and complex processing.

Another option is PHP, which was practically made for the purpose of generating HTML. You can run it on your pages to generate static versions, and just use "include" directives with that.

Yeah, glibc is extremely stable and you can be sure that an app compiled against it now will work well into the future. People just completely ignore that fact based on hearsay, and that the removal of a unused symbol hashing table from the glibc binary broke a few anticheat systems that were attempting to parse it.

Other libraries are the problem, usually. People are generally really good about changing the .so version of a library when the ABI changes in a backwards-incompatible way. Usually distributions ship both versions until everything they ship either has upgraded or been removed. Solutions like appimage can allow you to ship these libraries in your app.

They're just trying to prioritize linux applications, without preventing developers who want to support linux through wine from doing so.

The key difference is that applications ran under wine will always have some subtle quirks and misbehaviors that break the usability, that can be worked around by the dev when given the chance to.

What do you use?