SELF-DRIVING TECHNOLOGY SHOULD BE STANDARDIZED AND OPEN SOURCE.

Any other implementation puts profits over human lives.

Yes. What a strange question...as if hivemind fads are somehow relevant to the merits of a technology.

There are plenty of useful, novel applications for AI just like there are PLENTY of useful, novel applications for crypto. Just because the hivemind has turned to a new fad in technology doesn't mean that actual, intelligent people just stop using these novel technologies. There are legitimate use-cases for both AI and crypto. Degenerate gamblers and Do Kwan/SBF just caused a pendulum swing on crypto...nothing changed about the technology. It's just that the public has had their opinions shifted temporarily.

Trains are awesome and I fully support them but let's not be idealistic here and pretend that true self driving cars will never happen.

Edit: jokes on you! I made a grammatical correction that makes your reply IRRELEVANT. 😉

Yes. Case in point: there are at least 10 Lemmy iOS apps. I'll give you ten guesses on which ones are actually native Swift...

There are a quite a few Android apps in progress too. How many are written in Kotlin?

The Finest Possible Caprese Sandwich:

• fresh Baked Stirato Italian Baguette
• fresh Mozzarella di bufala
• fresh-picked Heirloom Italian Genovese Basil
• fresh-picked San Marzano Tomatoes
• Frantoia 100% Italian Extra Virgin Olive Oil
• Mediterranean Sea Salt
• Giuseppe Giusti Premio Italian Balsamic Vinegar

Judging by the state of the US, you're much more likely to be right than I am, you cynical bastard!

😂

https://en.wikipedia.org/wiki/Spaghettification?wprov=sfti1

NixOS!

Over the last decade, free software developers have been repeatedly tempted by development tools that offer the ability to build free software more efficiently or powerfully.

The only cost, we are told, is that the tools themselves are nonfree or run as network services with code we cannot see, copy, or run ourselves. In their decisions to use these tools and services—services such as BitKeeper, SourceForge, Google Code and GitHub—free software developers have made “ends-justify-the-means” decisions that trade away the freedom of both their developer communities and their users. These decisions to embrace nonfree and private development tools undermine our credibility in advocating for software freedom and compromise our freedom, and that of our users, in ways that we should reject.

In 2002, Linus Torvalds announced that the kernel Linux would move to the “BitKeeper” distributed version control system (DVCS). While the decision generated much alarm and debate, BitKeeper allowed kernel developers to work in a distributed fashion in a way that, at the time, was unsupported by free software tools—some Linux developers decided that benefits were worth the trade-off in developers' freedom. Three years later the skeptics were vindicated when BitKeeper's owner, Larry McVoy, revoked several core kernel developers' gratis licenses to BitKeeper after Andrew Tridgell attempted to write a free replacement for BitKeeper. Kernel developers were forced to write their own free software replacement: the project now known as Git.

Of course, free software's relationships to nonfree development tools is much larger than BitKeeper. The source to the free software development support service SourceForge was once available to its users but its authors have returned to a completely closed model. While SourceForge is built using free software, SourceForge users interact with the software over the web. Because users never have any copy of the SourceForge software, they can never demand source. Similar projects like CollabNet's Tigris.org, Google Code's “Open Source Project Hosting” services, and GitHub, each served similar purposes and have kept their code similarly out of reach. Their services are often provided without charge and promoted for free software development, but this commitment does not extend to their own software that runs the development platforms. The source code to each of these systems remains private and unmodifiable by the developers using the services.

These nonfree development tools present a dilemma for many free software developers. The goal of many of these tools is, through more efficient free software development, more free software and more freedom. CollabNet, Google and GitHub each claim to want free software to succeed and claim they want to help it. For a series of reasons though these companies choose to support software freedom through means that are less in line with free software ethics than the ones they seek to create. The result is developers who are disempowered. The software freedom of the code these hackers produce is contingent on unacceptable exclusivity.

First, the use of nonfree tools sends an unacceptable message to users of the free software produced. “Software freedom is important for you as users,” developers seem to say, “but not for us.” Such behavior undermines the basic effectiveness of the strong ethical commitment at the heart of the free software movement. As those that are already committed to free software, we should demonstrate that we can succeed—and thrive—using free software. We should support free alternatives to proprietary systems such as Savane which can replace SourceForge or Google Code and runs GNU Savannah, or Gitorious which can replace GitHub—by using them and by improving them in the areas where they fall short.

Secondly, we should realize that, going forward, the software we produce is only as free as the software it depends on for its continued use, distribution, and evolution.

The GNU GPL license and source code mean little to a user attempting to modify a program without free access to the software required to make that modification. It is not only developers' freedom at stake but, eventually, their users and all future “downstream” developers as well. Those choosing to use nonfree tools put everyone at the whim of the groups and individuals who produce the tools they depend on.

While proprietary development tools may help free software developers create more free software in the short term, it is at an unacceptable cost. In the controversial area of private software and network services, free software developers should err on the side of “too much” freedom. To compromise our principles in attempts to achieve more freedom is self-defeating, unstable, and ultimately unfair, to our users and to the larger free software development community.

Just as the early GNU maintainers first focused on creating free tools for creating free software, we should ensure that we can produce software freely and using unambiguously free tools. Our failure to do so will result in software that is, indirectly, less free. We should resist using tools that do not allow us the freedoms we are trying to provide our users in the development of their software and we should apply pressure on the producers of our development tools. Free software has not achieved success by compromising our principles. We will not be well served, technically, pragmatically, or ethically, by compromising on freedom of the tools we use to build a free world.

I think I would just need one. We'd have to work in opposing shifts to get my billion Euro idea out the door in a more reasonable time frame than the one I have currently been working in.

NixOS

I'm an intellectually overqualified filmmaker surrounded by anti-intellectuals (I routinely get made fun of for being interested in technical stuff)....and right now, I am on workman's comp with a broken foot. So: exactly what I am doing right now is exactly what I would want to be doing.

What's that?
Hanging out with my daughter in my lab,

Learning

• Haskell/Plutus
• Purescript
• using Nix to glue them together
• hacking an espresso machine (either with a RISC_V Lychee Pi or an ESP32...haven't decided yet).

Practicing:

• guitar

Blazing:

• chronic

In my case, whether I’m wrong or not, they actively discourage me from using my brain.

Mlem is my favorite too but they have a long way to go to catch up to Memmy for most of the functionality. It feels very solid compared to Memmy, though.

I'm finding the signal to noise ratio is higher here. Much higher quality content at the moment. I even see some bots that post the entire article rather than just linking it. I hope that catches on.

The funny thing is, OP’s link works on Memmy and yours doesn’t.

🤣

In my experience, Voyager is still pretty buggy too. For example, try editing a post then go to do anything else after the fact. I always have to restart the whole app when I go to edit a post I made. They have a ton more features than anyone else but there are still tons of bugs.

react native is another layer and lags behind the dev of swift by at least a year. This is a huge problem for new api's like SwiftUI, in my experience. Ps. Native is ALWAYS better than an approximation of native.

I think you’re probably just a dickhead.

This amazing interview with Philip Wadler dances around this very topic quite eloquently.

Here's the conclusion of the paper Wadler is referring to in this interview:

Proposition as Types informs our view of the universality of certain programming languages. The Pioneer spaceship contains a plaque designed to communicate with aliens, if any should ever intercept it (see Figure 9). They may find some parts of it easier to interpret than others. A radial diagram shows the distance of fourteen pulsars and the centre of the galaxy from Sol. Aliens are likely to determine that the length of each line is proportional to the distances to each body. Another diagram shows humans in front of a silhouette of Pioneer. If Star Trek gives an accurate conception of alien species, they may respond “They look just like us, except they lack pubic hair.” However, if the aliens’s perceptual system differs greatly from our own, they may be unable to decipher these squiggles. What would happen if we tried to communicate with aliens by transmitting a computer program? In the movie Independence Day, the heroes destroy the invading alien mother ship by infecting it with a computer virus. Close inspection of the transmitted program shows it contains curly braces—it is written in a dialect of C! It is unlikely that alien species would program in C, and unclear that aliens could decipher a program written in C if presented with one. What about lambda calculus? Propositions as Types tell us that lambda calculus is isomorphic to natural deduction. It seems difficult to conceive of alien beings that do not know the fundamentals of logic, and we might expect the problem of deciphering a program written in lambda calculus to be closer to the problem of understanding the radial diagram of pulsars than that of understanding the image of a man and a woman on the Pioneer plaque. We might be tempted to conclude that lambda calculus is universal, but first let’s ponder the suitability of the word ‘universal’. These days the multiple worlds interpretation of quantum physics is widely accepted. Scientists imagine that in different universes one might encounter different fundamental constants, such as the strength of gravity or the Planck constant. But easy as it may be to imagine a universe where gravity differs, it is difficult to conceive of a universe where fundamental rules of logic fail to apply. Natural deduction, and hence lambda calculus, should not only be known by aliens throughout our universe, but also throughout others. So we may conclude it would be a mistake to characterise lambda calculus as a universal language, because calling it universal would be too limiting.

I disagree.

IMO, we should be using Nix and OCI.

I’m working on convincing lemmy devs to start hardening their platform from attack…

That’s just like your opinion, man.

Which leads me to ask: why are we still using Docker images as a MAJOR part of our infrastructure when superior alternatives exist? The Docker aspect made me realize how hacked together the codebase actually is.