TechNom (nobody)

I wonder if these trillion dollar companies offer support contracts for astroturfing on social media on their behalf. I can't think of any other way so many people are supporting their sociopathic attitude.

They aren't talking about using recursion instead of loops. They are talking about the map method for iterators. For each element yielded by the iterator, map applies a specified function/closure and collects the results in a new iterator (usually a list). This is a functional programming pattern that's common in many languages including Python and Rust.

This pattern has no risk of stack overflow since each invocation of the function is completed before the next invocation. The construct does expand to some sort of loop during execution. The only possible overhead is a single function call within the loop (whereas you could have written it as the loop body). However, that won't be a problem if the compiler can inline the function.

The fact that this is functional programming creates additional avenues to optimize the program. For example, a chain of maps (or other iterator adaptors) can be intelligently combined into a single loop. In practice, this pattern is as fast as hand written loops.

Mir is not a good example of distro engineering, because it's an extreme case of NIH syndrome. Unlike what it is today, the original Mir was an alternative to Wayland.

The story started when Canonical decided that X isn't good enough and they needed an alternative. They chose Wayland first, exciting the entire Linux desktop community. But then they dropped Wayland in favor of the new in-house Mir project, citing several drawbacks to Wayland. The Wayland community responded with several articles explaining why Canonicals concerns were unwarranted. But in typical Canonical style, they simply neglected all the replies and stuck with Mir.

This irked the entire Linux community who promised to promote Wayland and not support Mir at all. This continued for a while until Canonical realized their mistake late, like always. Then they repurposed Mir as a Wayland compositor.

Now this is a repeating story. You see this with Flatpak vs Snap, Incus vs LXD, etc. The amount of high handedness we see from Canonical is incredible.

Interesting that they started dictating what you can and can't do with YOUR program! Consumer rights are a joke to these quasi-monopolies.

Nobody knows about unifiedpush. Last time I checked, their Linux dbus distributor also wasn't ready. There has to be a unified push to get it adopted.

CUDA is an API to run high performance compute code on Nvidia GPUs. CUDA is proprietary. So CUDA programs run only on Nvidia GPUs. Open alternatives like vulkan compute and opencl aren't as popular as CUDA.

Translation layers are interface software that allow CUDA programs to run on non-Nvidia GPUs. But creating such layers require a bit of reverse engineering of CUDA programs. But they are prohibiting this now. They want to ensure that all the CUDA programs in the world are limited to using Nvidia GPUs alone - classic vendor lock-in by using EULA.

Here's one issue they hope to solve with this rewrite: https://github.com/fish-shell/fish-shell/issues/238

All the problems mentioned here are common to various tech jobs and possibly other fields as well. It's nothing specific to programming. All problems mentioned are societal issues and not inherent problems of any profession. Things like student loans, hustle culture that leads to burnout, over compartmentalization of work, clueless managers, etc. We need a social revolution, not a career change.

Funny. I have the opposite experience with git. Use GUI for simple tasks and drop to CLI when it's complicated or when something goes wrong.

Discord is absolute trash if you're a user searching for solutions. It simply doesn't turn up in web searches. Why would you want your users to ask the same questions again and again?

I can recommend Rust - I'm training a few people on it.

And a pure functional programming language like Haskell or Scheme, if you don't know what functional programming is, or are not comfortable with it. Functional programming needs a different mental approach to traditional (imperative) programming paradigm. Some of the more modern languages like Rust, JS and Python incorporate a lot of functional programming constructs. So it makes sense to learn them.

And a lisp - Common Lisp's popularity is a public secret. Scheme is also fine. This family is homoiconic (program and data are treated more less the same). The syntax is actually very close to its AST. This gives Lisp unparalleled metaprogramming capabilities - mostly through macros. Macros in traditional languages are nowhere near Lisp Macros.

If it interests you, study a stack based language like Forth or Factor. Though they feel very different from Lisps, they have similar underlying properties. And you get more or less the same advantages.

So many praises for Windows and Mac about 'premium features', 'corporate environment' and 'device support'. But not enough talk about how they treat customers like crap and cash cows. Windows is replete with spyware and ads. It doesn't respect the user's choices, like when not to do an update or opening the links with a browser of user's choice. Heck! Some versions don't even allow you to register users without a cloud account. And now they are taking definite steps towards ensuring that you can't do anything they don't approve - with TPM and pluton non-sense. Praising windows is like being in an abusive relationship and finding justifications for it.

Mac is on the other extreme. They lock down their platform more and more in every revision in the name of security. It's getting harder to side-load apps. Why? For security, of course! No mention of how security comes primarily from platform design. Then there is the hardware, where everything is glued, soldered, riveted, digitally locked, etc, etc. Any small issue, and it's garbage. Not even parts from another genuine Mac can be used. Macs also have the strange distinction of needing calibration and signing of any part that can be replaced at all. It's deliberately designed to extract more money from you and create a tonne load of e-waste (iWaste?). Mac fanbois have a habit of justifying it in the name of 'miniaturization' and progress. Honestly, that's just hand-wavy and completely wrong technical argument. And Apple says it is all for 'privacy' and 'security' while their actual reason is the pursuit of double-digit growth (not just profits). So, in effect, Apple is saying to their customers "Oh honey! You're are just too stupid to take care of it. So let me just decide for you" - all the while squeezing you for money. Does it end there? Oh no! They need developers to pay a yearly fee and want to take a huge cut from their profits. All that for "providing the engineering, platform and services". As if the exorbitant price they extract from their customers isn't enough.

The hardware situation on Linux distros and frankly even BSDs isn't as bad as it is projected by some. Most devices just work even on a live installation medium. Even Nvidia works. (Have you considered the possibility that if any device doesn't work, it's the manufacturer's fault and not the OS's? There are plenty of devices for which the community maintains the drivers, just because the device manufacturer isn't an utter trashbag). There are tonnes of games too - thanks to Valve and Proton. And as for the 'corporate env', you are probably just locked in or too used to them. There are users who have been on these platforms for decades now without complaints. And there are companies built entirely on them. Can you say the same about any of the company that makes your OS/devices? Is there one among them that doesn't use Linux or BSDs?

Look! I'm not claiming that everything is rosy on the Linux and BSD side of things. Sometimes you have to find an alternative way of doing things (there are plenty of options). Sometimes, you have to configure a lot. Sometimes, you have to carefully choose your hardware so that your life is easier with Linux and BSDs. But there is one thing they don't ask you to do- and that is to surrender your self-respect. You don't get treated like cash cow. You don't get spied on as if you are a thief. You don't get restricted like a school kid. You're not told that your choices are wrong. Your choices are not disrespected. You don't get treated like you owe them after you paid your hard earned money on the devices they make. Ultimately, it's up to you to decide if the little conveniences are bigger than your self-respect.

I don't think that this is a hard rule. They probably look for the same signs that we do - plausible sounding utter gibberish. They just don't want the drop in quality due to that. If an author creates content with AI, but takes their time to edit and improve it, I think that the Gentoo team may give it a pass.

You think that's going to convince them? Plenty of people consider Apple as the second coming of the messiah. They would cheer if Apple dropped a bucket load of crap on their desk.

After reading the comments on several communities including Lemmy, reddit, YouTube and several others, I don't get the feeling that FOSS users are as enthusiastic about discord as you portray. Has it ever occurred to you that perhaps it's a restriction that you impose on your users?

Besides, all the bells and whistles of Discord don't solve the biggest gripe that I have with it - the searchability and discoverability of questions and answers. Despite the history recording in Discord, it acts essentially as an information black hole. People's efforts in solving problems are just lost because they can't be found again.

And finally, there's one thing that corporate social media has proven time and again. Eventually all of them pivot for some reason or another. Perhaps they want to monetize the platform on unacceptable terms (like reddit recently). That will happen to discord too some day. They are holding the community content hostage. Don't make the mistake of thinking that they won't ever try to make money off it, cutting the community from it.

The main issue for me is the syntax, specifically generic types, traits, and lifetimes.

After working almost exclusively with Go for years, reading it seems unnecessarily demanding.

Like someone else said, this is a complex subject to answer. The syntax looks perplexing and frustrating, until it doesn't. These days, Rust syntax is nowhere in my thought while coding - it like when you drive, you are thinking about where you want to go rather than about manipulating the controls.

Why should I learn and use rust?

Rust''s rules are about enforcing memory safety. But it also ends up forcing you to write better programs than what you imagined you could. It's hard to describe that feeling - you have to experience it. That alone is a good reason to learn it - even if you end up not using it in the future.

Rust's unique design also leads to many design patterns not normally seen in most other languages. That's also worth exploring.

I have fallen in love with Go. It feels like ‘home’ to me

That's a perfectly good thing. It's hard to find that sweet spot. However, don't let that stop you from exploring the alternatives. You might find ideas you could use in Go.

People are quick to judge without considering the circumstances. Wasn't the customer's attitude equally wrong? Aren't you implying that the service person should have let her bully him?

I agree that merge is the easier strategy with amateurs. By amateurs I mean those who cannot be bothered to learn about rebase. But what you really lose there is a nice commit history. It's good to have, even if your primary strategy is merging. And people tend to create horrendous commit histories when they don't know how to edit them.

You can uninstall the sudo application and add sudo as an alias for run0 in your shell initialization script. That's better than them renaming run0 to sudo, because that will prevent people from running the real sudo if they want it.

More like a personal bias in the form of a distasteful snark that the author thinks is funny. Their demonstrated knowledge about Emacs in the article indicates the worth of such remarks.

The entire purpose of Microsoft standardizing OOXML and implementing it wrongly in Office was to make other office suites irrelevant. ODF was already standardized and countries would have adopted it if MS didn't do the same with OOXML. They stuffed the ISO with members supporting them to do it.

And now that OOXML is a viable standard, they implement it wrongly so that other office suites can't be compatible with MS Office without a lot of extra effort. Any incompatibilities with MS Office will be considered as the fault of other office suites by the general public and government officials.

Expecting MS to do what's right for the customers is putting too much faith in their nonexistent sense of ethics.

Have you really used Rust or are you spreading FUD? I have not managed to cause even a single segfault in my 8 years of writing Rust code. Nor have I heard anyone else complaining about it, other than deliberately as proof of concept.

Those same companies tell you that their products that you paid for don't belong to you. You are just buying a license to use them. Sadly, this asinine concept is spreading even to hardware markets.

I think it's fair to ask them to take their own bitter pill. They should also invest without owning.

Torvalds really worked on his attitude and it shows. It's pretty evident from his interviews that he doesn't want the attention due to brash behavior. Even this news article is hyperbolic. He is just trying to get a point across. He's pretty much self restrained otherwise.

Commonmark leaves some stuff like tables unspecified. That creates the need for another layer like GFM or mistletoe. Standardization is not a strong point for markdown.

That's misinformation. There's no overestimation. The problem is so bad that even the US government advocates the use of memory safe languages (including GC languages).

I have used C and C++. You need laser sharp focus to avoid memory safety errors even after you learn what causes them and how to avoid them. It's significantly easier to write programs in Rust because any lapse in care to avoid memory safety bugs are caught by the compiler.

Crowdstrike exists for Linux too. In fact, it apparently crashed RHEL and Debian a few months back. That didn't get so much attention.

Falcon seems to be a cross between an antivirus and an intrusion detection system (IDS). There are many antiviruses on Linux, but only one FOSS AV is popular - ClamAV. As for IDS, snort is an example.

But in the true sense, Falcon is much more than just an AV and IDS. It's a way to detect breaches and report it back to CrowdStrike's threat detection and analysis teams. I don't think there exists a proper alternative even in the commercial sector.

Discord is an OK chat app. But it's TERRIBLE as a support forum. It's precisely the latter that everyone is complaining about.

Python decided to use a single convention (semantic whitespace) instead of two separate ones for machine decodeable scoping and manual/visual scoping. That's part of Python's design principle. The program should behave exactly like what people expect it to (without strenuous reasoning exercises).

But some people treat it as the original sin. Not surprised though. I've seen developers and engineers nurture weird irrational hatred towards all sorts of conventions. It's like a phobia.

Similar views about yaml. It may not be the most elegant - it had to be the superset of JSON, after all. But Yaml is a semi-configuration language while JSON is a pure serialization language. Try writing a kubernetes manifest or a compose file in pure JSON without whitespace alignment or comments (which pure JSON doesn't support anyway). Let's see how pleasant you find it.

This is an old post and a lot has changed since then. Many of the points in that article are no longer true. Drew himself started a language - hare, for which he is considering Rust style borrow checker to ensure safety. It's a bit wrong to bash anything based on a half a decade old opinion.

Exact same story here. Bash -> Python -> Rust.

Generally speaking, people should settle on a compiled language if they can. They can iterate as fast as interpreted languages these days.

Edit: If you want to try something different in scripting, try the execline language. Its interpreter processes the script and exits immediately even before the script execution begins. Traditional shell interpreters (like bash) stay active till the entire script is finished. Execline achieves this by a clever chaining of Unix execs, forks and variable substitutions. This makes execline scripts lighter (useful in embedded systems), more secure and less error-prone than traditional scripts. The downside is that writing them will feel a bit weird - since the fundamental paradigm is different from regular shells. However, that will be a refreshing change if you're someone who likes to experiment and try new things.

They're a trillion dollar company acting like a petulent child

No. They're a trillion dollar company acting like a greedy dirty scum that they are.

I didn't know he was alive. But he was a legend enough to be known. It's sad when the world loses a mentor like him. RIP!

I don't know if you're talking about panics and abort or about crashes caused by memory safety errors. The latter class is very unlikely in safe rust, other than as rare compiler bugs. Panics and aborts are your call. You can easily write code that doesn't panic or abort.

So you can't get a Rust program to segfault without trying really hard. I haven't observed a single segfault in the normal Rust code I wrote in the past 8 years.

We need three four things:

1. A way to poison the data that will throw off the training without causing perceptible difference to humans. As I remember it, many image AIs were sensitive to a peculiar noise that was imperceptible to humans.
2. A skiplist of AI data stealers, so that their IPs/domains can be blocked in bulk.
3. Eventually, the above technique will become useless as AI data stealers will start using dynamic IPs and botnets to bypass the skiplists. We'll need to throttle or block data to visitors based on pattern recognition. For example, if the visitor requests linked pages in rapid succession. Or if the request interval is uniform or pseudo random, instead of genuinely random.
4. If the pattern recognition above is triggered, we could even feed the bots with data from AI models, instead of blocking or throttling. Let the AI eat its own s**t.

LXD was under the Linux containers project earlier. After the Canonical takeover of LXD, the following changes were made:

1. The repo privileges of the original LXD developers were revoked. Those developers are driving the development of Incus now.
2. LXD's license was changed to AGPL+CLA

The first point means that Incus is the true successor of the original LXD. The current LXD is a jealously guarded pet project of Canonical in the same manner as Snap and Mir.

As for the second point, I'm usually a proponent of AGPL. But CLA corrupts it so much that it's more harmful than with a permissive license. The real intention of this license change is to prevent Incus from incorporating changes from LXD (since the copyleft license of LXD code is incompatible with the permissive license of Incus). Meanwhile LXD continues to incorporate changes from Incus, although the Incus developers haven't signed any CLA. This move by Canonical is in very bad faith, IMO.

So yes - I consider LXD to be untrustworthy. But that doesn't cover the old LXD code, its developers or its community. Those transformed fully into the Incus project the same way OpenOffice was forked into LibreOffice. And I don't trust the LXD name anymore in the same way nobody trusted the OpenOffice name after the fork (before it was donated to the Apache foundation).

Systemd is too egotistic to even mention Linux. They will simply name it systemd-defenderd.

Don't believe me? See this!

I looked at the post again and they do talk about recursion for looping (my other reply talks about map over an iterator). Languages that use recursion for looping (like scheme) use an optimization trick called 'Tail Call Optimization' (TCO). The idea is that if the last operation in a function is a recursive call (call to itself), you can skip all the complexities of a regular function call - like pushing variables to the stack and creating a new stack frame. This way, recursion becomes as performant as iteration and avoids problems like stack overflow.

Peter Thiel is insolent enough to say out loud what these companies practice - 'competition is for losers'. These quasi-monopolies aren't here to provide the best value - quite the opposite. They want to kill all competition by any dirty tactic and then use the diminished choice to wring the customers of every penny they have. They want to extract maximum revenue by making sure that their inferior solution is the only option customers have.

This problem isn't solvable by market regulation alone. The world has enough a*****es around who will climb to the top of successful companies and find ways around the regulations. They're being as bad as they can, while skirting the limits of what's illegal. My main gripe is with the engineers, programmers, technicians and all technical creators who enable these scumbags. It's not hard to see that supporting a proprietary solution amounts to yielding the consumers' bargaining power to a monopoly. Despite that, they keep making these choices. For example, it's not uncommon to hear senior engineering managers or technical-lead level employees saying, "I know that Chrome is spyware and I want to quit it. But this works only on Chrome". I feel like screaming at them that if they're too incompetent to demand a change at the level they're at, they're in the wrong profession.

If you're a technical creator, your choices matter. It affects a lot more people than you alone. But more often than not, I see such creators surrendering principles in exchange for convenience. They hold as much responsibility as the market-abusers in making the world the way it is now.