Then there is the rest of us that just install a distribution and use it with whatever it comes with to do whatever we need without even knowing which window server we are using, or even what that is.
I have no idea what the percentage is but I’m quite confident that it is much higher today than it was in 2008. Ubuntu was first released in 2004 and in 2008 one of it’s big selling points was nvidia proprietary driver installation and display auto-configuration. The people who decided to ditch Xorg likely and correctly thought a large portion of the user base was eager to walk away from all of those headaches. As time has progressed, most of this work has been done by desktop environments and distros, often in collaboration with each one another. We’re probably at a point where most linux desktop users have never had to manually install a driver or manually configure their graphics hardware.
I think I stopped having to change my xorg.conf by about 2003. There was an awkward interval when I got a second monitor after Xinerama but before XRandR when I had to explain the screen layout. But after XRandR, drivers and display configuration were solved problems for me, so I didn’t have headaches to walk away from.
We’re probably at a point where most linux desktop users have never had to manually install a driver or manually configure their graphics hardware.
We are at that point no doubt. Having done all those things manually in a past that starts to feel remote, I see very little point on leaving such things to the end user. People (myself included) just want stuff that works.
What I find somewhat ironic is that present day windows and osx do not satisfy that requirement either. They provide two half-assed desktop environments full of idiosyncrasies.
I admit I dropped off after the article said Wayland doesn’t have a strong reference implementation, so your program might break on a different implementation, which is a big problem that you won’t have with X, because you simply don’t care about other implementations than Xorg.
I admit I dropped off after the article said Wayland doesn’t have a strong reference implementation, so your program might break on a different implementation, which is a big problem that you won’t have with X, because you simply don’t care about other implementations than Xorg.
I think the problem is less the lack of a canonical reference implementation, which was actually true for X11 for a long time, too. In the days of commercial unix vendors they all shipped their own implementations and multiple ISVs sold mac and windows servers. XFree/Org won out by being free and covering almost all hardware, but it wasn’t always that way.
However, it mostly wasn’t a necessity to have a custom x server, but a choice. Whereas now it seems like the answer to a huge variety of “How do I do X in wayland?” questions is “Write a compositor”
… which to me is equally as bad as web developers who write off Firefox support because it works in Chromium.
Competing implementations is good, albeit at the expense of more work for developers. I get frustrated as an end-user when, say, IMEs don’t work because nobody can agree on the spec that should be used to implement them, or when we have multiple competing implementations of video screensharing (between GNOME’s dbus-based API and the xdg-desktop-portal-based world), but then I remember: the alternative is a monoculture where nothing can challenge the platform’s assumptions.
I eagerly await viable Wayland implementations on, say, OpenBSD and NetBSD, so that it’s no longer “just a Linux, and somewhat FreeBSD, thing” and we can evolve the modern FOSS desktop with multiple implementations per platform. May the best ideas win.
I agree with you in spirit. We should all start with a goal of broad compatibility. However there is a huge difference in the degree of effort required to achieve cross-compositor compatibility versus cross-browser compatibility. For some wayland extensions it would be akin to hosting your web application on multiple different web servers that were each bug-for-bug compatible with different browsers at the HTTP level or even the transport level.
I eagerly await viable Wayland implementations on, say, OpenBSD and NetBSD, so that it’s no longer “just a Linux, and somewhat FreeBSD, thing” and we can evolve the modern FOSS desktop with multiple implementations per platform. May the best ideas win.
Arcan supports OpenBSD so I guess it’s closer to broad cross-Unix compatibility, and would fulfill your desire for multiple competing implementations per platform.
At the core of my complaints is the fact that distributing an application only as a Docker image is often evidence of a relatively immature project, or at least one without anyone who specializes in distribution. You have to expect a certain amount of friction in getting these sorts of things to work in a nonstandard environment.
This times a thousand. I have tried to deploy self-hosted apps that were either only distributed as a Docker image, or the Docker image was obviously the only way anyone sane would deploy the thing. Both times I insisted on avoiding Docker, because I really dislike Docker.
For the app that straight up only offered a Docker image, I cracked open the Dockerfile in order to just do what it did myself. What I saw in there made it immediately obvious that no one associated with the project had any clue whatsoever how software should be installed and organized on a production machine. It was just, don’t bother working with the system, just copy files all over the place, oh and if something works just try symlinking stuff together and crap like that. The entire thing smelled strongly of “we just kept trying stuff until it seemed to work”. It’s been years but IIRC, I ended up just not even bothering with the Dockerfile and just figuring out from first principles how the thing should be installed.
For the service where you could technically install it without Docker, but everyone definitely just used the Docker image, I got the thing running pretty quickly, but couldn’t actually get it configured. It felt like I was missing the magic config file incantation to get it to actually work properly in the way I was expecting to, and all the logging was totally useless to figure out why it wasn’t working. I guess I’m basically saying “they solved the works-on-my-machine problem with Docker and I recreated the problem” but… man, it feels like the software really should’ve been higher quality in the first place.
no one associated with the project had any clue whatsoever how software should be installed and organized on a production machine. It was just, don’t bother working with the system, just copy files all over the place, oh and if something works just try symlinking stuff together and crap like that.
That’s always been a problem, but at least with containers the damage is, well, contained. I look at upstream-provided packages (RPM, DEB, etc) with much more scrutiny, because they can actually break my system.
Can, but don’t. At least as long as you stick to the official repos. I agree you should favor AppImage et al if you want to source something from a random GitHub project. However there’s plenty of safeguards in place within Debian, Fedora, etc to ensure those packages are safe, even if they aren’t technologically constrained in the same way.
I agree you should favor AppImage et al if you want to source something from a random GitHub project.
I didn’t say that. Edit: to be a bit clearer. The risky bits of a package aren’t so much where files are copied, because RPM et al have mechanisms to prevent one package overwriting files already owned by another. The risk is in the active code: pre and post installation scripts and the application itself. From what I understand AppImage bundles the files for an app, but that’s not where the risk is; and it offers no sandboxing of active code. Re-reading your comment I see “et al” so AppImage was meant as an example of a class. Flatpak and Snap offer more in the way of sandboxing code that is executed. I need to update myself on the specifics of what they do (and don’t do).
However there’s plenty of safeguards in place within Debian, Fedora, etc to ensure those packages are safe
Within Debian/Fedora/etc, yes: but I’m talking about packages provided directly by upstreams.
Within Debian/Fedora/etc, yes: but I’m talking about packages provided directly by upstreams.
Regardless of which alternative, this was also my point. In other words, let’s focus on which packagers we should look at with more scrutiny rather than which packaging technology.
AppImage may have been a sub-optimal standard bearer but we agree the focus should be on executed code. AppImage eliminates the installation scripts that are executed as root and have the ability to really screw up your system. AppImage applications are amenable to sandboxed execution like the others but you’re probably right that most people aren’t using them that way. The sandboxing provided by flatpak and snap do provide some additional safeguards but considering those are (for the most part) running as my user that concerns my personal security more than the system as a whole.
On the other side, I’ll happily ignore the FHS when deploying code into a container. My python venv is /venv. My application is /app. My working directory… You get the picture.
This allows me to make it clear to anybody examining the image where the custom bits are, and my contained software doesn’t need to coexist with other software. The FHS is for systems, everything in a dir under / is for containers.
That said, it is still important to learn how this all works and why. Don’t randomly symlink. I heard it quipped that Groovy in Jenkins files is the first language to use only two characters: control C and control V. Faking your way through your ops stuff leads to brittle things that you are afraid to touch, and therefore won’t touch, and therefore will ossify and be harder to improve or iterate.
I got curious so I actually looked up the relevant Dockerfile. I apparently misremembered the symlinking, but I did find this gem:
RUN wget --no-check-certificate https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
RUN bash Miniconda3-latest-Linux-x86_64.sh -b -p /miniconda
There was also unauthenticated S3 downloads that I see I fixed in another PR. Apparently I failed to notice the far worse unauthenticated shell script download.
I’ve resorted to spinning up VMs for things that require docker and reverse proxying them through my nginx. My main host has one big NFTables firewall and I just don’t want to deal with docker trying to stuff its iptable rules in there. But even if you have a service that is just a bunch of containers it’s not that easy because you still have to care about start, stop, auto-updates. And that might not be solved by just running Watchtower.
One case of “works on docker” I had was a java service that can’t boot unless it is placed in /home/<user> and has full access. Otherwise it will fail, and no one knows why springboot can’t work with that, throwing a big fat nested exception that boils down to java.lang.ClassNotFoundException for the code in the jar itself.
I maintained the CHERI LLVM fork for a long time (now I maintain a fork of that). Other folks are still maintaining the fork of FreeBSD for CHERI. I’ve worked on a few in-house forks of compiler things at various points and worked with companies that had in-house forks of FreeBSD.
I think it’s worth characterising them according to why they won’t merge upstream, typically in the following groups:
Upstream doesn’t want the patches.
It’s experimental and will churn a lot before it’s in a good place to ask for review.
It holds something that gives competitive advantage.
The first reason happens when you have rare requirements. It’s usually worth engaging with upstream here to see if anyone wants some of the infrastructure for your work. A number of the things that we did for CHERI in LLVM, for example, ended up being useful for AMD GPUs because they also had weird pointer semantics. Folks building managed-language VMs also wanted a stronger separation of pointer and integer types, so we worked with them on some things. Similarly, Juniper wanted stable, parseable output from various command-line tools and it turns out that they weren’t the only ones, so they upstreamed libxo and integrated it with things like ifconfig, so their tooling could just consume JSON or XML output.
The second is common in research prototypes. A lot of these are thrown away (I have a load of these that showed that an idea was not, in fact, a good one). Others die for bad reasons. I’ve seen a few colleagues write papers about some LLVM optimisation but start with an old release and then not have the time to update to trunk and work (occasionally they’re just doing bad science: one abandoned a project because, after getting a CGO paper, they updated LLVM and found that their transform now gave a slowdown when their baseline was less naive). A lot good work in academia is wasted because no one budgets for the upstreaming time. In both FreeBSD and LLVM, I’ve tried to build connections between universities and companies that care about their research and can have engineers work to upstream it (which often involves a partial rewrite, but is usually cheaper than inventing the thing from scratch). The REF in the UK helps because getting things upstream into a widely deployed project counts for more in the impact metrics than simply publishing a top-tier paper.
The third category is often the hardest because it’s very rarely true. Most of the time, the secret sauce is easy for someone else to replicate. It’s also painful because, if it actually is valuable, upstream will implement the same feature in a different way. Now you have to decide whether to make your fork diverge more by ripping out an upstream feature, or throw away your work. If you pick option 1, remember that more smart people don’t work for you than do: the upstream version of the feature is likely to get more engineering investment than yours and so, over time, yours will get worse. Companies that do this well gradually trickle features upstream when it looks like someone else might want to work on them, so they have a small lead but get to share long-term engineering investment.
I would just add, there can be one other reason that I’m aware of, regulatory requirements. If you work in governments/for governments, they can have odd laws/rules, where the code has to exist and be “owned” by someone in country or in organization, etc. Lots of times that means you can’t just fork, you have to create from scratch, which is annoying. Sometimes you can though!
Sometimes it’s easy and it’s literally just a soft fork, where you can get away with just adding a changelog entry, “I own X here”. Sometimes you have to hard fork it for various reasons, and in those situations you usually don’t get to ever play with upstream again.
Though I guess now that I wrote this all out, this could maybe be a sub-category of your third reason.
For corporate deployments, you often need to have an internal soft fork to a repo and then do builds from there, so that the entire source-to-binary flow is on auditable systems. Microsoft does this with all open source that they distribute binaries for and I’ve seen similar flows for internal use elsewhere.
It’s less common now that a load of public CI systems are free for open source, but it used to be extremely common for open source projects to do binary releases from random contributors’ systems (LLVM still does this). This provides a great attack vector for malware: a targeted attack on a single developer can install malware that can then propagate to all users. Big projects typically build on isolated infrastructure (FreeBSD, for example, builds all packages on machines that are not connected to the Internet, so ensures that any malware must be present in the source tarballs, whose hashes are present in the ports tree and are thus auditable later). Newer small projects that provide binary releases will do so with something like Cirrus CI or GitHub Actions where each build runs in a pristine VM with known configurations and so malware needs to be committed to the repo (where it shows up in the git logs if someone looks carefully enough). Cloning the repo and building ensures that any malware that you inadvertently ship must be in the repo and can’t be deleted without your having a separate audit log that shows it was there.
I don’t really view this as forking though, because ideally the copy in your clone is identical to upstream’s. A few places do something like this but carry a handful of back-ported fixes.
FreeBSD, for example, builds all packages on machines that are not connected to the Internet, so ensures that any malware must be present in the source tarballs, whose hashes are present in the ports tree and are thus auditable later
How do the source tarballs get into these build systems?
It’s been a while since I looked at the infrastructure, so I’m not sure if this is still the case, but they were exported from a read-only NFS share. If you can compromise a builder, you then had to compromise the NFS server to the outside world. All packages are built with Poudriere, which builds each one in a jail, and also prevents any network access, so you first need a jail escape to get access to the network stack to try to attack the NFS server.
All these attempts to resurrect the “good old days” of the web smack of cargo culting. People are obsessed with the outer forms - Usenet! Blogging! - instead of the socio-economic reality. Back then, writing a blog was the most convenient and popular way of getting engagement online. Now, it’s not. The technology, and most important, the audience has moved on , and the methods of making money from it has too.
Unless I remember wrong, making money was not a concern for the participants of webrings. Only a (by definition) small and noisy subset of people were trying to optimize “engagement”. Webrings are about discovery, not profit.
Same here. Most of the websites I used in 1996 were made by people who were proud that they accomplished something that felt difficult or created a resource they had tried to find but couldn’t and wanted to save others time. Profit wasn’t part of it. A lot of these were hosted on space ISPs made available as part of dial-up plans so cost recovery wasn’t even part of it.
I do think the world has broken that mold though. The amount of stuff that does not exist or is very difficult to find on the web has shrunk drastically. This has reduced the potential for that intrinsic motivation to share useful resources. Similarly, it has become much, much easier to publish content on the web and to create software. This has reduced the frequency of people accomplishing anything that feels difficult and feeling proud enough to warrant building a bespoke website.
That was also true of blogrolls — in the early days. The for-profit blogger was a relatively late development, and one that contributed to the decline of blogs and the rise of social media as we know it.
People blogging for money have moved onto silos like Substack and Patreon. The rest of us are doing just fine, and couldn’t care less about “engagement” or chasing an upwards slope on our metrics dashboards.
I’m not against being able to make some money off blogging, but I don’t think the best blogging comes from making it a major source of growing revenue.
The technology, and most important, the audience has moved on , and the methods of making money from it has too.
The methods of making money have moved in. That is the problem, money making took over everything. Everything became about money, people reach content through a handfull of entry points that will give the spotlight to a couple of content makers per topic. All reachable through the same top list. Anything outside that filter will be relegated to oblivion and eventually die.
YouTube has recently removed the option of uploading videos without ads. Facebook, Instagram et al, have long stopped showing you what your connections are posting in favour or an algorithm that you can’t control nor know that will show you a bunch of stuff you didn’t ask for.
The opportunity for a small website with a stable following base is gone. Everyone gets sent to the big popular content sources instead. There’s also the network effect catalysing this.
If you search a topic on YouTube or Instagram, the results will consist of content producers whose success got to the point of them leaving whatever other job they add and become professional content creators. It became a competition for serious business while before there were amazing online resources visited by millions that were ran by some unknown dude in the Bolivian mountains or in deep in Siberia in his spare time.
Things got more suited for the masses, but the focus was taken away from the enthusiastic smaller group who did it out of passion.
The same can be observed in sports. When a sport becomes a successful venture, the participants become business owners. Full with business management made to optimize results at the expense of sportsmanship.
But it you follow any less professionalized sport, whenever there is a big international cup, the whole event becomes a genuine celebration of the passion for the sport, with displays of much more honest sportsmanship.
I feel like something millennials like me miss is that computers and the Internet don’t have the same emotional place in the minds of Gen Z. For us, it was the future. Something the previous generation didn’t understand, the next frontier to explore and have adventures in. Now millennials have bills to pay and children to take care of, so there’s much less room for excitement in our lives and the next generation sees computers and the Internet as a corner that’s already taken. Just another tool of the old world order used to exploit them. I wonder how much this picture contributes to the loss of innocence and beauty online.
The technology, and most important, the audience has moved on , and the methods of making money from it has too.
Good. Let them move on. Then we who feel curiosity and passion for the world just for its own sake are among ourselves again. I can do without the salespeople and SEO spam.
I whole-heatedly disagree. Reading blogs was nicer, more convenient and less weird, and it still is.
For quite some time I would have agreed with you, in many different contexts. The internet is filled with articles, videos, etc. claiming “you only remember the good bits”, “you only think it was great because it was the best back then”, “you are only being nostalgic”, “if you would try it again it would suck”.
Just today, co-workers complained about not being able to increase an input field on the website of one of the biggest companies. The other day I tried to contact my bank for the first time, since I needed to send documents I did it online and they have a really low character limit on their input field, so I had to upload my support message as a PDF.
Or look at how easy it used to be to just download a file into a directory. Try that on your phone when you have to.
At some point during the heights of the pandemic when I was being nostalgic I decided to put things to the test. Nope, Usenet is still nice, and nicer than alternatives, nope old video games still are nice, nope, doing stuff off the cloud is… not even still good, but better, than it ever was, using a desktop, better than it used to be, building your own desktop, woah, even the cheapest case feels like workstation quality back in the day, etc.
Managing music on your own system, instead of on some online platform is still so so much nicer, using things like Strawberry.
And none of those things are ever down, unlike CloudFlare, which made a habit of turning their downtime into an ad, or S3 or Google, or Slack, etc.
IRC is still better than Discord to get good, quick responses, and with IRCv3 it even got rid of any downsides.
In general, smaller communities tend to still be higher quality, than.. well, even lobste.rs.
Meanwhile, on big platforms, it’s all 404s, failing registration, logins, weird white pages, lots of JavaScript errors, with a lot of famous apps and application people started to get used to things not working. I mean not so long ago Video Conferences worked most of the time, but despite the pandemic and what not it’s a great big mess. Meanwhile good old Mumble just works.
And then the big news sites. Everyone lying about caring about your privacy, everyone wanting you to pay, acting like it’s donations, pretending to somehow be grass roots. While blogs just through out stuff there for free.
Also I started using Bandcamp for getting my music at the worst possible time I guess.
So in short: If you think that you probably just are nostalgic and think you are only remembering the good bits, go and verify that thought. There is a real chance that it still works great! Some stuff is even better now, BECAUSE the technology moved on, and because the trolls and self-promoters moved on.
I don’t know what you mean by cargo culting in that context. Could it be that you used the wrong term here? Maybe you talk about the circle jerking happening in some of those groups. That’s a thing. But sometimes you just have to dig a bit deeper. Or avoid (a big portion of) Gemini fans.
I don’t know what you mean by cargo culting in that context. Could it be that you used the wrong term here?
No, I chose it deliberately.
I sympathize with the desire to move towards a more user-centric internet. I too believe that the current social-media landscape is a morass of user-hostile surveillance and privacy violations.
But many (not all) of the proponents of “the small web” confuse the map for the terrain. They think the reason the early internet was less commercial was that people built stuff themselves, or only the very technical could host or even use a website. And they believe that if they go back to that technical environment, the web will become less commercial. But it (probably) won’t! Because the world has moved on. Everything is on the internet now.
This is in analogy with the real cargo cults, who thought that building replicas of the cargo planes that brought prosperity to islands during WW2 could bring them back.
I believe the best way to deal with internet surveillance capitalism is robust legislation protecting user’s rights to privacy. That’s going to be hard to bring about, and I don’t have the solutions for it. But I do know that if you want voters to demand that, you’ll need to reach them where they are. Shutting yourself in in exclusive networks is probably not going to work.
But many (not all) of the proponents of “the small web” confuse the map for the terrain. They think the reason the early internet was less commercial was that people built stuff themselves, or only the very technical could host or even use a website. And they believe that if they go back to that technical environment, the web will become less commercial. But it (probably) won’t! Because the world has moved on. Everything is on the internet now.
Interesting. I see it differently. First of all yes, there was a lot more self-build, non-commercial stuff. I was part of some of these things, from interest groups, to private usenet to private for fun game servers and games. People invested their own money and provided stuff they found fun, just like small private clubs.
The other thing is that I see a bit of a dis-illusionment. I don’t see many people that believe they can change it back. Much rather they try to separate to be able to do their own thing. You can still rent a server, a webspace, etc. and just run your own stuff. At least to some degree.
I think yes for some stuff (privacy) legislation is the right way, but for the fact that companies intend to squeeze money out of you. That’s somewhere between hard to impossible to fix. Every now and then a company is created with another goal than making money, but actually to satisfy a need, but typically at some point you end up with people that don’t care and just want to get the maximum amount of money with the least amount of work (which is fine).
Some stuff like having your small community does work. It’s why everyone tells you to join a user group and stuff.
I agree that making the web less commercial is going to happen, but I also don’t think any form of legislation is going to change that.
That, and I suspect there were a lot fewer people, and the people there were very driven to explore and express themselves with the new shiny thing at the time, and were willing to put up with the higher barrier to entry of the mediums available at the time.
Nowadays, there’s a bigger proportion of people with not much to say, and what they do want to say, they can say what they want on a medium they don’t have to maintain (modern social media) - and they like it this way.
It’s a deliberate distancing from “the way things are now”. Sure, you’re missing out on 99.9% of the audience. Lobsters is small (16k users, and far fewer active) because it decided to set itself apart from the norm, in a rather retro way. Yet people find it worth their while to post and comment here. It’s not because we’re driving those millions of ad impressions.
In my experience, when distros package software from other package managers what you typically end up with is dependencies that are years out of date. That is my experience with Ruby and Python deps, and those don’t even need a complicated build process! Compiled languages like Rust would probably be even worse.
As a result, I have zero faith in repackaged deps and never use them.
Those dependencies are only packaged in order to satisfy the application packages that rely on them. I can envision a very successful multi-language apt repository that focused more promptly on repackaging. It would require a massive amount of storage but it would enable a more universal solution and improved resilience through mirroring. It will probably never happen because it would require a huge amount of coordination (on par with Debian) but in theory such a project would allow large orga to offset their Artifactory licensing and operations costs.
When I first heard of MTE I was confused about how it different from CHERI. This MS article was very helpful for me.
MTE is in a very different place in the design space to CHERI. It aims for close to 100% binary compatibility with existing code. This imposes an upper bound on the security that it can enforce by requiring it to support idioms that may be secure in one context but not in others, for example casting a long to a pointer. It associates a 4-bit “color” with every 16-byte memory chunk and embeds the same color in the top bits of pointers, providing a lock-and-key mechanism where mismatches between the color in the pointer and the memory are detected by the hardware.
I think, with the benefit of hindsight, git should have been limited to the storage data model. It was meant to enable distributed workflows. There are multiple workflow options that can make good use of the data model. The data model is, some would argue, a fundamental reflection of the way software changes. So it makes a good candidate as a common dependency for version control tools to share. Most of the confusing terms, as far as I can tell, come from the limited and kernel-centric workflow support that was built into the early versions. That is compounded by centralized services like GitHub building atop a tool that already chose terms that assumed a much more distributed model of sharing work. If the kernel developers had put the fetch, push, pull, etc functionality into a lkml-dist tool then we would have likely seen GitHub build their own distribution tool that adhered more closely to the contours of their service, reducing at least some of the confusion in terms.
Git almost always uses commits in the first sense, and indeed that is their data model behaviour as well.
Cherrypicking changes the meaning because it would otherwise be useless. But that’s something specific to cherrypicking (and base-swapped rebase I assume).
I agree. However, people often tend to think as a commit as a set of changes (as evidenced by some comments here), so I think that proves my point that there is a lack of conceptual clarity.
Empirically I agree: people are confused by this. I am not sure the fault is the word “commit” though. I am curious what you would suggest instead. To play devil’s advocate and defend git, let’s look at the cherry-pick help:
Given one or more existing commits, apply the change each one introduces, recording a new commit for each.
Conceptually, this doesn’t necessarily rely on the concept of a set of diffs, as in a patch file. You can still have “commit” mean purely “committing the entire state of the working directory to disk” and have a coherent concept of cherry-picking: the “change being introduced” is merely the difference between the commit and its parent. Hence cherry-picking is fundamentally contextual and implicitly references two commits. And for that reason requires the -m flag on commits with multiple parents.
Cherry-picking also sets the state of the current working directory. When working with individual commits, I almost always want to also affect the current state in some way. So in that sense they are inherently intertwined. You could call them “revisions” or “changesets” or whatever, but I don’t think that would change the fact that in most workflows they are inherently coupled.
How so? In both cases IIUC you are just moving HEAD to point to a different commit.
If I asked you raise your hand, I think you would understand that to mean that you also have to move your arm, and the distinction isn’t really that important. It is not a problem in everyday speech that things stand in for other things.
Is it different for Git? HEAD is the name we give to the “current” commit used as the basis of comparison for the working directory state. So we already have different names for #1 and #2. But almost no one says “what commit is HEAD pointing at?”–they say “what commit are you on?” The distinction is there, but most of the time it’s not that important. I wonder if what you’re criticizing is not a feature of Git, but a feature of language itself.
The weird thing about HEAD is that it can have different types depending on context. In non-detached state, it’s a reference to a reference to a commit: a reference to the current branch, which itself is a reference to a commit. But in detached state, one of the levels of indirection collapses: HEAD is just a reference to a commit.
If you check-out a commit, you tell git to set HEAD to the state associated with that commit.
If you cherry-pick a commit, you tell git to compute the difference between that commit and its parent, try to somehow “apply” that difference to the current HEAD, create a new commit and set HEAD to that.
Both can fail if your working directory contains uncommited changes. The latter does a lot more, and it can also fail in a new way: When the contents of a file that is changed by the commit you’re cherrypicking have changed, you get a merge conflict. This is not possible (AFAIK) when checking out a commit.
Maybe you’re right and I am being pedantic. But in general I think it helps a lot when understanding concepts when you have clear names and not conflate things. With the current naming, it is hard to explain to a beginner what a commit is because it an overloaded term.
With the current naming, it is hard to explain to a beginner what a commit is because it an overloaded term.
Overloading the term would be to use the same term for different purposes or concepts. In git a commit is one thing. It is a recording the revisions made to a set of files. You can record them and once recorded you can consume them in multiple ways, each of which has a separate term. The word serves as both a noun and a verb but this doesn’t make it overloaded because the verb form is the act of creating the noun.
The two concepts you referred to have specific names. You used them: checkout and cherry-pick. Those are different actions you can take that each consume a commit (and create a new commit in the cherry-pick case). You can explain the relationship between the working directory and the commit to a beginner quite simply: if you have uncommitted changes to tracked files or even untracked files in your working directory, either stash them or commit them prior to consuming any other commit in any way.
My point is that a commit refers to a snapshot, but the term “commit” is also used to refer to the diff of the commit and its parent.
For example, in github if you click a commit SHA it will show you the diff with its parent, or when you cherry-pick it also considers diffs.
I think this is confusing to beginners (which most people here obviously aren’t) and a more explicit name should be used to distinguish between the two.
How does a commit affect the state of the working directory? It records the staged changes, which come from the working directory. I don’t know if any file changes it makes outside of the .git directory though.
I’ve learned to appreciate the virtue of manually juggling virtualenvs over “automatic” approaches.
If you need to support multiple Python versions, or test against multiple versions of dependencies, “automatic” management of virtualenvs by making them 1:1 with project directories just gets in the way.
Also interesting that the post dismisses pip-tools because it’s a third party tool which doesn’t come with Python and which you have to learn how to use, and then goes on to suggest using Poetry which has the same problem. pip-tools has worked well enough for my needs.
Same here. The “Automatic management of virtualenvs” is a big part of why I find pip replacements frustrating. One of the best features of virtualenvs is that you don’t have to activate them. If you simply run python/pip/etc from their virtualenv path then you are using the virtualenv. I have a handful of defacto project management scripts that assume the virtualenv is in project-local venv dir (overridable with an env var). It’s a few more pieces but they remain the same across projects so they are easy to build habits around. Most importantly though, exerything is local and explicit. No surprises.
I’m a fan of incremental approaches. I’m also a fan of some of the languages looking to replace C++. Overall this talk seems moving in the right direction. Maybe there could be a meeting of the minds in a few years. However this made me laugh out loud:
A complex system that works is invariably found to have evolved from a simple system that worked.
Is he really meaning to imply that modern C++ is simple?
John Gall’s saying is essentially about solving complex problems step by step, rather than trying to solve everything at once.
However, I think Bjarne is forcing this quote where it doesn’t belong, for two reasons:
C++ has strong backwards compatibility constraints, so it has limited ability to evolve.
He’s implying the other languages were foolishly starting from scratch, and thus couldn’t have arrived at a working complex design. But in terms of language design they weren’t starting from scratch — they’ve learned from C++’s mistakes, without having to keep them.
Also seems a little misguided. If your language/ecosystem is fully backwards compatible, does it still compile all the old crufty unsafe code? Yes, it does. Did you win anything then? Maybe, if you manage to completely compartmentalize your new stuff (probably want to have linter checks per file/module/subdir then?), and there are probably some benefits to be able to modernize the codebase on the go. But I don’t think a lot of people will do this in earnest, so it’s no real win.
There are two things that Bjarne is quite consistent about:
C++ invented everything first. Interestingly, according to this talk, C++ invented “safety”, although despite long ago inventing safety, C++ hasn’t yet delivered the design and implementation for that invention that it invented first before anyone else thought of that invention that C++ invented. But please wait, because it’s all coming soon, that thing that C++ invented first, long ago.
Anyone that attempts to take a different route than the route envisioned by C++ – including the heretical route of using a different language – is just crazy. In this presentation, the term he used to describe competing ideas is “fantasy”.
It’s a shame that Bjarne has no self-confidence, and takes his lack of confidence out on the rest of the industry. Bjarne’s work has been hugely successful, and that work can and should stand on its own merits. His constant need to tear down and undermine everyone else’s work is infantile and – quite obviously! – destructive.
I think he means to imply that the corollary to Gall’s law, “A complex system designed from scratch never works and cannot be made to work”, applies to Rust. Ignoring the fact that Rust started off as a comparatively simple system that evolved a lot before it reached 1.0. (To some extent by pruning ideas that were unfinished because they were simple place-holders for things that turned out to be too complicated.)
No, if I understand correctly he is saying modern C++ is complex but works, and it evolved from simpler systems that worked (old C++ and C before that).
I think this is trying to place it in contrast with other modern languages like Rust that (while also complex) did not evolve directly from any single existing language.
Is he really meaning to imply that modern C++ is simple?
Well not now, but in a few years’ time what we now call “modern C++” will certainly seem a lot simpler than what we’ll call “modern C++” then!
I’m only half joking. I hate C++‘s complexity but the fact that Gall’s Law uses an absolute rather than a comparison term is just an unfortunate rhetorical exercise – IMHO it should read “simpler”, not “simple”, which is kind of obvious in the book’s original context (Gall wasn’t an engineer, most of the “systems” he talks about aren’t technical systems, and his book is pretty light-hearted in terms of discourse, it’s not a rigorous scientific book).
If one admits that modern C++ works – not the most uncontroversial statement, but anyway :-P – expanding it to cover additional safety idioms isn’t completely out there. For all its tortuous history and shabbiness, C++ does have a long history of evolving features successfully.
This is a misfire. The author is conflating a “bad language” with “a language with a different purpose”.
Shellscript is optimized to call external programs and pipe outputs and inputs between them. And it favours streams of bytes/strings rather than other data types. It does so at the expense of sacrificing other things like quoting or type safety. The people complaining that is a bad language, are the same ones that would complain if their prompt would throw NaN errors or if it would require special syntax for variable expansion or quoting all parameters. The design is such intentionally! The shortcomings were design choices.
Shellscripts are more testable than other languages, as you have for example a prompt shell for it always available. Then even have an error debugging channel built in (stderr).
I hate to be so negative, but I hear such opinions as the ones in this post every other week, and it is pretty much a function of how un familiar with shellscripts people are.
The design is such intentionally! The shortcomings were design choices.
To me the two biggest issues in shell scripts are quoting and continue on error by default. I could maybe see a choice behind quoting (“nobody uses spaces in their paths and this way we get arrays”) but what could be the intention behind continue on error?
It’s not about spaces in tabs, it’s about having the most simple possible syntax to pass multiple parameters, just separate them by spaces.
The intention of continuing on error is to emulate an interactive shell session. But you can change that to exit on error very easily on your scripts if you want.
The use of “load-bearing” also seems quite off the mark.
Eventually, much of our system’s core business logic found its way into the script (metrics collection, a basic killswitch system, retry logic, etc.). This system was particularly challenging to manage because the script wasn’t even static. Our backend used Go templates to assemble the script dynamically and send it to the CI environment.
Given this example, I think “Avoid Homer Simpson Car Shell Scripts” may have been a more apt title :) I believe shell scripts are actually serving us best when they are load-bearing, for accurate definitions of load-bearing. The author seems to think load-bearing means something like “Durable enough to serve at the core” but it actually means something more like “Can efficiently spread the load”. Where is it spreading the load? Down to the foundation. In other words, shell scripts are most useful when they provide enough connective tissue between foundational components to allow each of those components to serve their intended role well.
I see this as relevant beyond just the terms because the language seems to elicit an inverted sense of architectural responsibility:
The load-bearing script becomes problematic because it becomes difficult to change.
Load-bearing structures are usually designed simply, with an understanding that they will be extremely difficult to change. I would agree that shell scripts should not be used for a part of your product that will need to be changed a lot. With an eye toward the earlier example, why is retry logic or a killswitch something that needs to change often? The entire arrangement sounds like it was built upside down.
I didn’t have the patience to go through their wall of small text. I always thought “the cloud” meant renting someone else’s computers and letting them take care of the scaling, backups and failovers. Is this just a … on prem server farm?
I view it as a modern version of the mainframe. One big box arrives at your doorstep. You plug it in and everything is already there and you can use it.
I find the mainframe comparison useful. The things that keep it from being a true mainframe are no longer as important to many – it’s not so important it doesn’t act as a single large computer, or bake more reliability features deep into the hardware (vs. say handling high database availability mainly by failing over). 64-core/1TB RAM/32TB SSD nodes are large enough for a lot already, and most apps are already written as a distributed system where app processes talk to DBs, caches, queues, and storage services–like, that’s the norm even when scale doesn’t require it. (Also, this product has bits like distributed block storage that bring a bit of that “big reliable hardware” illusion back.)
What is like a mainframe, from a business perspective, is:
you’re buying a thing as a capital expenditure
one purchase is supposed to cover CPU, RAM, storage, and interconnect for your whole workload, and all the overprovisioning you need for HA/continuing after failures, non-prod servers, etc.
one vendor is taking responsibility for integration and reliability of the overall system (I hope; at the prices I expect they charge, it doesn’t seem like they can shrug at reliability issues).
With the technical aspects of a true mainframe much less in demand today, and the mainframe-like aspects it does have being rare today, it does feel like a modern mainframe in some relevant sense.
I wonder if the potential market–essentially, folks who want to own the resources of at least 16 of these compute sleds and have some real dissatisfaction with using a cloud vendor–will bite at this, or prefer racking Supermicro servers and generic switches or using some other flavor of non-big-3 hosting. The buzz itself might actually be what lets this take off enough to get a durable foothold when similar-seeming things have not. Of course, it also needs to work well in practice, something not really proven yet, and it has to be priced so the business can work!
I also wonder if Oxide or others are going to offer cloud hosting based on this. With what they have today, it’d be very different from what the big providers offer (just as “cloud” offerings from older-school hosting providers are), but I could see selling it on things like the latency/bandwidth advantages of a group of nodes and their storage all being connected to the same top-of-rack switches; you might be able to gin up good benchmarks based on that.
from what I read, it seems like it’s a low-hassle server farm, complete with software and firmware updates. It also seems to be configurable via APIs, similar to the cloud. I imagine you could terraform VMs and resources on it.
Unlike the cloud, you don’t pay a perpetual “tax”, it’s just a one-time purchase. Reading a few articles lately (e.g. DHH) about going on-prem from the cloud, the big argument against going back to on-prem is the hassle, and this seems to address that fairly well.
FWIW, we have an EBS-like block storage system, but we do not yet have an S3-like object store (the economics of bulk object storage on all-flash systems are not fantastic anyway). I think it’s pretty reasonable to think of it as in the EC2 space at this early moment! We’re excited about layering more on top in the future.
(Edit: I guess I don’t really think of IAM or VPC or Route 53 as being separate from EC2, but it you do, we have stuff in those areas also!)
I don’t have an Oxide Rack brochure sitting in front of me to type out all the features. You might want to do some investigation to evaluate whether it’s just “random VPS provider in a box” or not.
The real point that is being made in this thread is that it’s not a rack that does nothing. It’s a rack that, within hours of being delivered off the truck, can be setup and used to provision production workloads. Their goal is to reduce that time as much as possible.
That is a great feature set. It is however besides the point calling it “AWS in a box”, which what I am trying to say. AWS has hundreds of services, from very low level to very high level. There is no way that you get anything close to that from Oxide. You get the hardware you could build that on, yes. Will it be highly integrated hardware/software and probably quite good? I guess so. I trust their taste. Is this “AWS in a box”? No it is not. That’s all.
That’s probably not an unreasonable way to think about it. One idly wonders if they’ll have a marketplace for service implementations that run on Oxide machines that can cover more of the use cases than “compute + storage + IAM auth”.
Cloud means a lot of different things. That is why nearly every analysis of deployment choices related to the cloud comes with a hefty pile of caveats. The cloud is all of:
Locating your compute in a data center.
A software layer provided by the data center to orchestrate the hardware.
Relying on the data center to pre-acquire hardware.
Associated software services that scaffold atop the orchestration layer to serve a COTS/SaaS role.
The Oxide rack handles the second and it allows you to handle the first and third. Those three together make up the 2011-ish version of AWS. The fourth is a more recent maturation of the cloud offerings. Given Oxide’s young age, they aren’t their yet, but I suspect they could grow to serve a similar role.
Usually the cost of these things is a rental fee. However that is a sales strategy by the cloud provider. The advantage to them is that rental fees present a perpetual option to increase prices and to increase the services used by a customer. Cloud providers could choose to sell their customers a portion of their data center, along with a futures contract for power and network delivery. As growth slows, I suspect we will see relationships like this, along with the associated financialization and arbitrage that goes along with those types of relationships.
Those three together make up the 2011-ish version of AWS. […] The fourth is a more recent maturation of the cloud offerings
In 2011 AWS already had (next to EC2 and S3) EMR, RDS, ELB, SNS, IAM, Route 53, Elastic Beanstalk, SES which are all in the 4th category. I would not call that a “recent maturation”.
So, a stupid question. In the new cold Wayland world, what’s to prevent running Xwayland rootful and just running all your apps in that? That should support everything that you’d want from X but doesn’t require you to run Xorg directly … right?
If so, then why did we throw the baby out with the bathwater?
You could run Xwayland in a single-app compositor like cage, yes. That’d give you the ability to run on hardware X doesn’t support (i.e. Apple and some other ARM SoCs)
Yes, you could do that. It kinda sorta works. Just don’t use anything modern with that approach, such as GTK4 because it introduces visual bugs for window decorations. I don’t remember the details but it has something to do with GTK4 introducing a new renderer that tries to make more direct use of modern hardware.
The parts of X11 that had to be thrown out revolve mostly around display management and relating visual output to input events. The X11 model for display management was to define a virtual screen and let the video drivers find a way to make the actual displays map to the virtual screen. This precludes any conventional, reliable model for handling changes in display topology, handling heterogeneous displays, vsync, etc.
So if you run X11 program in Xwayland you get to benefit from all of those display management improvements.
The potentially interesting question is whether you can manage Wayland windows with an X11 window manager using this approach. I wonder if it would be possible for a Wayland compositor to delegate window decoration and similar to an X11 window manager running in XWayland. This would require handling reparenting events and probably hooking into the composite / render / damage extension to identify some of the window management operations, but it might be possible. I bet a lot of objections to Wayland would go away if it provided a way for people to run their favourite existing window manager.
Learned that by coding with a friend I considered a terrible coder.
I worked with him on a lot of fun projects, because we get along well, and he really doesn’t know what he is doing, copy / pasting all other the place, no archi, no design, bad naming… Half of the time he’s not sure what the code is really doing.
And it works.
I noticed how in the end he accomplished more than I did. He didn’t sweat the small stuff, he worked more, way more, as well. He didn’t write unit tests, but he always tested everything manually again and again by playing with the result like a kid.
In the end I embraced the idea.
I wanted to code a contact software because all the ones I tried didn’t do what I wanted. I didn’t, I just used django-admin and called it a day instead of trying to craft some slick UI. I’ve been using that terrible stack of forms for 10 years, and it did the job.
I needed a cli for totp years before any existed, I just fired Python and dumped, in clear text, the seeds in TOML. Took me half a decade to add encryption to it, because symlinking the file from a veracrypt container was sufficient and required little work.
2 months ago I wanted a timer to top up a time budget when I do sport, and consume it when I play video games (https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_…). I just splatted a wall of tailwind regurgitated by chatgpt and pupetted by HTMX. Turns out it was just enough. I show that to my friends that were asking me wtf I was doing with this, and 4 people asked me an account, one a trial for doctors for addiction programs (!). Don’t even have a register form, I hard coded them :)
Wish I told my young self to stop being so obsessed with doing things right or even working on important problems. I never managed to reach “right” in my entire life anyway.
But I switched back and I am very curious about what your take on this is, but isn’t that really boring? At least to me “just throwing stuff together” gets really boring really quickly and that’s why I (mostly) stopped again. It gets to the point where it’s uncomfortably so.
Could be because it’s my hobby too though. I feel like that might be the difference for some people.
This is why most of my work is in languages lacking strict typing and without much immediate IDE feedback. I really appreciate types in a lot of situations. However I learn the most from intentionally breaking software by making some small changes and predicting how it will break at runtime and then checking my hypothesis. It’s often hard to justify any particular line of exploration at the time but in sum all of these experiences have repeatedly made me much better prepared than a lot of my colleagues to debug difficult issues. Having a sense for how things run under a lot of different broken assumptions gives me a good distribution of points within the search space to triangulate between.
That the real value of the cloud is in managed services and new architectures, not just running the same software on rented cloud instances. It’s basically the “you’re holding it wrong” argument for the cloud, and it’s hogwash.
I dunno man, managed services are more expensive, that’s really the point of them. EKS adds cost, being managed (also, feels a bit misleading to not mention the migration from k8s to Kamal, the in-house tool they developed to manage deployments). You can get better pricing with EC2 spot instances and manage them yourself. Last I checked RDS Postgres costs about 2x an EC2 instance (Aurora even more), and maybe an extra 15, 20% using whatever storage you use on RDS vs EBS. Good for them saving all this money, but DHH doesn’t have to be such a persistent gnat about it. I guess they must be saving that massive tax expenditure, that shocked me when I saw it but made sense.
He’s posted essentially the exact same thing 5+ times. His company left the cloud - that’s great, and I’m glad it’s working out well for them. I don’t think we need monthly updates of DHH repeating himself for internet clout.
Obviously we all know that we can hide things. Clearly enough people have seen enough of this to agree. People here would generally not like if a less well-known individual rewrote the same post 5 times and continued to repost it here. This situation with DHH is no different.
Obvious: You don’t gotta read it. Nobody’s forcing you, complaining about other people being repetitive is not particularly great.
He broke down something new, I believe. That’s worthwhile to some people, I would imagine, even if he’s touched on the same topic elsewhere this is new (I believe) detail.
Whatever happened to telling people not to worry about other people’s reaction and just write / blog? I’d much rather people keep throwing things out into the ether for me to decide if they have value than to tell people to self-edit and be inhibited about things.
Maybe you don’t need his updates, but he needs to work it out and writes about it. That’s to be encouraged, IMO.
I get tired of certain topics, I understand fatigue with things or authors or topics, but IMO it is a net negative to the world to complain about something like this that doesn’t cause any harm.
Whatever happened to telling people not to worry about other people’s reaction and just write / blog?
DHH is a very wealthy CEO writing blogspam to promote his businesses, which are about “collaboration” and getting people to email more “effectively”. He’s not some literally poor random blogger just putting his words out there.
I know who he is. But he’s not forcing you to read this, and as things go this is firmly in the category of Mostly Harmless. It’s, at worst, kinda stale content. It’s perhaps contrarian but not harmful, and I don’t see what purpose it serves for people to complain that he blogs too much. I do see the harm in other people internalizing the idea that “oh, I’ve written about this topic a few times so now people are going to be tetchy with me for doing it again.”
(Source: Have spent a significant part of my career working with tech folks on blogs, and getting past the idea that once they’ve touched a topic they can never do it again for fear of being repetitive is often difficult.)
I read several of them, and my take is that all but the first supplied additional details. All but the first could IMO be summarised as “we’ve continued [project] with [more results] and it still is going well. [More details, including numbers]”, with results/details/numbers on different parts.
IMO this is fine, because he posts it on his blog, it interests someone, and if he hadn’t done it then people would post things like “ah, but did you notice that he stopped posting about how well it succeeded quite early in the project? Draw your own conclusions!!!1!”
Sure there are some people (including you) who didn’t doubt that the rest of the project would be a great success, and for you the additional postings are free of content. But so what? Restrict your blog posting to that which pleases everyone, and you won’t post anything at all.
DHH doesn’t have to be such a persistent gnat about it.
I dunno, I appreciate high-profile folks speaking out against the “commonly accepted wisdom” or hype. And DHH has always been well-known for being a bit of a douche bag.
Alright, but take a look at the list of features from RDS. It’s not just “apt-get install PostgreSQL” as a service. There’s a very non-trivial amount of engineering effort (and, consequently, money) required to:
implement the same feature set
do it correctly and robustly
maintain and update it
And by non-trivial I mean multiple people/year. That’s easily millions (a couple, but still, millions) in personnel costs alone.
Now, of course, you might not need all that. But if you did needed it, but didn’t get it, it might mean all your data is fucked. That kind adds a shitload of grains of salt to the savings proposition.
And this translates to a lot of managed things: kubernetes, object storage, block storage, functions as a service, Kafka, queues, notifications, etc.
That’s what I’m saying. DHH doesn’t need all these managed services because Basecamp etc are all established businesses that understand their infrastructure requirements. If I were starting a business I’d use RDS, but for DHH what was the advantage?
I’ve implemented database thingies both on our own databases and on cloud services, for startups that didn’t understand the 1.0 needs well and had to get something done. You could say: Databases that had to run first in order to learn what they should eventually be.
My impression is that doing it with AWS wasn’t less work for us than doing on our own RDBMSes or on our own NoSQL DBMSes. AWS was quite different in how the hours were spent, in the details of the work. But the amount of work to get our needs going on AWS was quite comparable to that on Postgres or that maligned NoSQL thing whose name I’ve forgotten.
I won’t say equal, because I did it at different companies for different needs. The work was different. But comparable in hour count, yes.
The thing I find missing from this is how to provide backpressure with a latency queue. With a priority queue or a job-specific queue, it is (fairly) easy to say drop X jobs if we know we can’t get to them. But if the only differentiator is latency requirements, we don’t get that (eg. An 8hr latency might be critical but a 15ms latency can be a job that is dropped worst case).
Largely I think it comes down to tradeoffs, I’m not sure you can ever really have one queue strategy to rule them all.
When Rails people talk about background jobs it’s almost entirely just for the sake of moving a slow SMTP conversation out of the middle of an expensive HTTP conversation, welcome emails and the like. There’s not normally a conversation about back pressure or dropped jobs because having way more space than you need (in this case, Good Job keeps its queue in your app’s main SQL database, so you’re probably already over provisioning ) is cheaper than reasoning about what you can afford to drop.
Dropping jobs is not quite the same as back pressure but in the frame of your comment they are both methods of avoiding infinite scale-out. That scale-out is likely informed by metrics and selective back pressure mechanisms can be applied based on the job metrics. e.g. paths that enqueue less critical, shorter latency jobs can return errors to their callers that the subsystem is temporarily unavailable. However, in practice, on the timelines you pose, it would likely be a bug causing some jobs to take much longer than anticipated or a known temporary workload increase in which case a temporary change to the scale-out limit would be approved and implemented. De-prioritizing the longest max latency jobs is what gives you a semi-confortable human-scale timeline on which to react. e.g. you have alarms set for the 4 hr mark on jobs with a max latency of 8 hrs.
Not a lawyer, but I always thought of MIT license as a license, and GPL as a contract. The GPL is like a nation’s constitution, a contract engineered to grant and protect freedom.
The legal idea is that “license” and “contract” aren’t mutually exclusive categories. Loose OOP analogy: license and contracts are interfaces that a deal can implement, not different, single-inheritance parent classes.
Legally, “license” is a “defense” to copyright infringement. If you get sued under copyright, you can beat the case by pointing to evidence you had permission to do what you did. Legally, “contract” means either side, and potentially other people who weren’t part of the agreement but were meant to be benefited by it, can sue to enforce the terms of the deal. That’s different than suing for copyright infringement, which is about someone else copying, sharing, and doing other specific things with a creative work that the law gives you ownership of.
MIT sets a lot fewer rules than the GPLs. But there is a requirement to keep copyright and license notices on the software. There is also a big chunk of disclaimer language at the end, which responds to some defaults in contract law.
But uhhh what? It’s a contract. There’s an offer, acceptance, and consideration. Calling a duck a squid doesn’t stop courts declaring it quacks. MIT license is a contract but I’m not a lawyer and don’t see the consideration in it’s terms, just offer and acceptance, so “license” it is. Don’t ask me to explain what a license is - I don’t know, I just know it gives you permission to do something.
Not a lawyer, so I don’t know to what extent MIT license terms could provide consideration. Maybe not suing your upstream. Derivative works being shared in return definitely is consideration, though.
Derivative works being shared in return definitely is consideration, though
I disagree. It would be if the GPL had a condition that you must share derived works with upstream, but it requires only that you share them downstream. This means that there is nothing that upstream receives as a result of the license (they may receive the changes because it’s cheaper to send them upstream than maintain a fork, but that’s an orthogonal concern).
Yes, it does; consideration must be something valuable, although it doesn’t have to be material.
In this situation, the typical understanding is that, absent the GPL, there is no permission given for any usage of the code; all rights are reserved according to standard copyright law.
I am not a lawyer, but it feels like a big stretch of that definition to view a constraint on sublicensing (you may sublicense only if you impose the same terms on those that you sublicense to) as a consideration.
I think the advertisement of the licensee as a user of the GPL’d software as well as the advertisement of the availability of the source code could be argued with a straight face to be of value to the publisher. Notoriety is of value after all. Both celebrities and companies have been award damages for harm to their reputation.
edit: it occurs to me now that you may have been pointing to the conditional nature of the GPL. i.e. if the licensee does not distribute then the publisher would not receive any notoriety. However there are a lot of contracts like this in other legal areas such as real estate, mergers, and finance.
This is probably complicated in the US, because moral rights are state law not Federal, but in Europe you have the right to demand attribution does not rely on a contract or explicit license.
I’m not sure that it is, because you’re not promising to release changes, you’re agreeing to be bound by conditions if you distribute and impose those conditions on everyone that you distribute to. You’re receiving a set of rights that’s less than unlimited redistribution, but if I give you £10 you’re not giving me £5 simply because I didn’t give you £15.
The consideration must have some value to the contracting party who is offering the product or service. It’s hard to imagine that any reasonable person would agree that a nebulous possible future modification has any value. For example, what is the estimate of the value? If you are a public company and you go to your shareholders and try to convince them of this value, are you likely to be laughed out of the room? (Yes.)
To put it another way–if you can claim that this promise is consideration, then you can also claim that a promise to, in the future, possibly write and publish a technical article is consideration in exchange for a good or service offered. Which, again, no reasonable person would agree with that.
Software licenses are not contracts. Otherwise why do you have to accept an EULA (End User License Agreement) in order to use software installed on a phone that you have already bought? I.e. you executed a contract with the party who sold you the phone, you paid them the consideration in exchange for the phone, and now you still need to accept a license or else you can’t actually use the phone. Clearly, the license is separate from the contract.
That example makes sense because phones don’t ship with an Android CD and license key. Or I suppose an Android SD card would make more sense, assuming the phone has a slot for one of those.
Because the money you paid was for the hardware. The EULA is granting you permission to run certain software on that hardware. If you don’t accept it, you can still use the hardware but you can’t use the software.
It is not the case, legally speaking, that something which grants you certain rights/permissions to software must be either precisely 100% license and 0% contract or precisely 100% contract and 0% license; it is possible for something to have aspects of both, or to be interpreted differently by different courts or in different situations.
Oh man, this gets complicated because in the US you often don’t actually “own” the hardware in the sense that you can do anything with it. This is part of the reason for the “right to repair” movement. Zod, I love all the complications we as consumers have as a result of capitalism.
You own the hardware. If someone came and physically took it from you, you could report it as theft, for example, and seek to have it returned to your possession. And you can dispose of it as you choose (within the bounds of local laws about things like disposal of batteries and electrical components, of course). And so on – you have the rights normally associated with ownership.
It might be the case that you do not have and cannot easily obtain the tools to reliably disassemble and reassemble the device to a working state, or to replacement parts which will work with the device, but stretching the definition of “ownership” to include a mandate to provide those things is, well, a stretch. Which is one reason why I tend to fight back, hard, against any attempt to make “ownership” synonymous with “easily end-user repairable and manufacturer is required to provide parts and tooling and training in their use on demand”.
The only reliable “contractual components” are “a court rules that it is a contract”.
Naming something a “license”, for example, doesn’t bind a court to finding that it isn’t a contract, any more than starting a brutal dictatorship and calling it the Glorious People’s Democratic Republic of Liberty makes that name accurate.
OK, so where is the court ruling that free software licenses like GPL are contracts? Because in the absence of that, I am inclined to give credence to an actual software licensing lawyer: https://lobste.rs/s/rmhnw9/we_were_wrong_about_gpls#c_qmgu2v
OK, so where is the court ruling that free software licenses like GPL are contracts?
There was one out of France a few years ago that did come to this conclusion. Though the French legal system is quite different than the American one so there’s not much value in that decision here.
The article this whole comment thread is about was written by a lawyer.
As C.S Peirce would say, we have now reached the limits of the “method of authority” as a dispute resolver – two authorities disagree. Sooner or later we must move on to the “method of science” – in this case, of performing experiments in the real world (court cases, rather than blog posts or essays or wiki pages) and seeing how they turn out. But I suggest you keep your mind open to the possibility that the result might be, as I said originally, that the answer will be “not 100% license and also not 100% contract but a mix of both”.
Like I said, in the absence of a court ruling, I will look at other sources. And yes, I will look at authoritative sources first, because usually they’re authoritative for a reason. If we are being scientific, then statistically an authoritative source is more likely to know something relevant about the matter.
The answer may be ‘it’s a mix of both’, but a specific one needs to be chosen for the purposes of application to this specific case. And that’s what I’m interested in.
There is no “authoritative source”, though. There are different lawyers with different positions, and you’re just sort of arbitrarily picking one to declare as “authoritative”. On what grounds?
I thought we were talking about authoritative sources because your argument was that we were debating by ‘method of authority’. It’s a matter of who you consider more authoritative, I guess, and I consider Eben Moglen, a free software lawyer and professor, to be pretty authoritative on it. OP less so not so much because I don’t know them, but more because I can’t make heads or tails out of their point.
OP is an attorney well known for writing about software licensing and open source.
Again it seems difficult to find grounds to say “I choose this lawyer as authoritative over all others”. At that point it’s less “authoritative” and more “arbitrary”.
An EULA is a contract. It forms an offer (the software), acceptance (your use of the software), and consideration (the terms of the agreement - access to the software in return for following the terms of the agreement).
Unlike EULAs, free software licenses do not work as contractual extensions to existing legislation. No agreement between parties is ever held, because a copyright license is simply a declaration of permissions on something that otherwise would be disallowed by default under copyright law.[5]
The reference [5]:
Eben Moglen (10 Sep 2001). “Enforcing the GNU GPL”. gnu.org. Free Software Foundation, Inc. Archived from the original on 26 April 2013. Retrieved 20 May 2013. Licenses are not contracts: the work’s user is obliged to remain within the bounds of the license not because she voluntarily promised, but because she doesn’t have any right to act at all except as the license permits. … [C]ompanies say their software is “licensed” to consumers, but the license contains obligations that copyright law knows nothing about.”
Then there is the rest of us that just install a distribution and use it with whatever it comes with to do whatever we need without even knowing which window server we are using, or even what that is.
I suspect we are 95-99% of the total user base.
I have no idea what the percentage is but I’m quite confident that it is much higher today than it was in 2008. Ubuntu was first released in 2004 and in 2008 one of it’s big selling points was nvidia proprietary driver installation and display auto-configuration. The people who decided to ditch Xorg likely and correctly thought a large portion of the user base was eager to walk away from all of those headaches. As time has progressed, most of this work has been done by desktop environments and distros, often in collaboration with each one another. We’re probably at a point where most linux desktop users have never had to manually install a driver or manually configure their graphics hardware.
I think I stopped having to change my xorg.conf by about 2003. There was an awkward interval when I got a second monitor after Xinerama but before XRandR when I had to explain the screen layout. But after XRandR, drivers and display configuration were solved problems for me, so I didn’t have headaches to walk away from.
We are at that point no doubt. Having done all those things manually in a past that starts to feel remote, I see very little point on leaving such things to the end user. People (myself included) just want stuff that works.
What I find somewhat ironic is that present day windows and osx do not satisfy that requirement either. They provide two half-assed desktop environments full of idiosyncrasies.
How far we’ve come.
Save the Linux desktop from what, exactly?
I admit I dropped off after the article said Wayland doesn’t have a strong reference implementation, so your program might break on a different implementation, which is a big problem that you won’t have with X, because you simply don’t care about other implementations than Xorg.
I think the problem is less the lack of a canonical reference implementation, which was actually true for X11 for a long time, too. In the days of commercial unix vendors they all shipped their own implementations and multiple ISVs sold mac and windows servers. XFree/Org won out by being free and covering almost all hardware, but it wasn’t always that way.
However, it mostly wasn’t a necessity to have a custom x server, but a choice. Whereas now it seems like the answer to a huge variety of “How do I do X in wayland?” questions is “Write a compositor”
… which to me is equally as bad as web developers who write off Firefox support because it works in Chromium.
Competing implementations is good, albeit at the expense of more work for developers. I get frustrated as an end-user when, say, IMEs don’t work because nobody can agree on the spec that should be used to implement them, or when we have multiple competing implementations of video screensharing (between GNOME’s dbus-based API and the xdg-desktop-portal-based world), but then I remember: the alternative is a monoculture where nothing can challenge the platform’s assumptions.
I eagerly await viable Wayland implementations on, say, OpenBSD and NetBSD, so that it’s no longer “just a Linux, and somewhat FreeBSD, thing” and we can evolve the modern FOSS desktop with multiple implementations per platform. May the best ideas win.
I agree with you in spirit. We should all start with a goal of broad compatibility. However there is a huge difference in the degree of effort required to achieve cross-compositor compatibility versus cross-browser compatibility. For some wayland extensions it would be akin to hosting your web application on multiple different web servers that were each bug-for-bug compatible with different browsers at the HTTP level or even the transport level.
And the end result is that many Linux-compatible app developers just give up and use electron.
Arcan supports OpenBSD so I guess it’s closer to broad cross-Unix compatibility, and would fulfill your desire for multiple competing implementations per platform.
This times a thousand. I have tried to deploy self-hosted apps that were either only distributed as a Docker image, or the Docker image was obviously the only way anyone sane would deploy the thing. Both times I insisted on avoiding Docker, because I really dislike Docker.
For the app that straight up only offered a Docker image, I cracked open the
Dockerfilein order to just do what it did myself. What I saw in there made it immediately obvious that no one associated with the project had any clue whatsoever how software should be installed and organized on a production machine. It was just, don’t bother working with the system, just copy files all over the place, oh and if something works just try symlinking stuff together and crap like that. The entire thing smelled strongly of “we just kept trying stuff until it seemed to work”. It’s been years but IIRC, I ended up just not even bothering with theDockerfileand just figuring out from first principles how the thing should be installed.For the service where you could technically install it without Docker, but everyone definitely just used the Docker image, I got the thing running pretty quickly, but couldn’t actually get it configured. It felt like I was missing the magic config file incantation to get it to actually work properly in the way I was expecting to, and all the logging was totally useless to figure out why it wasn’t working. I guess I’m basically saying “they solved the works-on-my-machine problem with Docker and I recreated the problem” but… man, it feels like the software really should’ve been higher quality in the first place.
That’s always been a problem, but at least with containers the damage is, well, contained. I look at upstream-provided packages (RPM, DEB, etc) with much more scrutiny, because they can actually break my system.
Can, but don’t. At least as long as you stick to the official repos. I agree you should favor AppImage et al if you want to source something from a random GitHub project. However there’s plenty of safeguards in place within Debian, Fedora, etc to ensure those packages are safe, even if they aren’t technologically constrained in the same way.
I didn’t say that. Edit: to be a bit clearer. The risky bits of a package aren’t so much where files are copied, because RPM et al have mechanisms to prevent one package overwriting files already owned by another. The risk is in the active code: pre and post installation scripts and the application itself. From what I understand AppImage bundles the files for an app, but that’s not where the risk is; and it offers no sandboxing of active code. Re-reading your comment I see “et al” so AppImage was meant as an example of a class. Flatpak and Snap offer more in the way of sandboxing code that is executed. I need to update myself on the specifics of what they do (and don’t do).
Within Debian/Fedora/etc, yes: but I’m talking about packages provided directly by upstreams.
Regardless of which alternative, this was also my point. In other words, let’s focus on which packagers we should look at with more scrutiny rather than which packaging technology.
AppImage may have been a sub-optimal standard bearer but we agree the focus should be on executed code. AppImage eliminates the installation scripts that are executed as root and have the ability to really screw up your system. AppImage applications are amenable to sandboxed execution like the others but you’re probably right that most people aren’t using them that way. The sandboxing provided by flatpak and snap do provide some additional safeguards but considering those are (for the most part) running as my user that concerns my personal security more than the system as a whole.
On the other side, I’ll happily ignore the FHS when deploying code into a container. My python venv is /venv. My application is /app. My working directory… You get the picture.
This allows me to make it clear to anybody examining the image where the custom bits are, and my contained software doesn’t need to coexist with other software. The FHS is for systems, everything in a dir under / is for containers.
That said, it is still important to learn how this all works and why. Don’t randomly symlink. I heard it quipped that Groovy in Jenkins files is the first language to use only two characters: control C and control V. Faking your way through your ops stuff leads to brittle things that you are afraid to touch, and therefore won’t touch, and therefore will ossify and be harder to improve or iterate.
I got curious so I actually looked up the relevant
Dockerfile. I apparently misremembered the symlinking, but I did find this gem:There was also unauthenticated S3 downloads that I see I fixed in another PR. Apparently I failed to notice the far worse unauthenticated shell script download.
I’ve resorted to spinning up VMs for things that require docker and reverse proxying them through my nginx. My main host has one big NFTables firewall and I just don’t want to deal with docker trying to stuff its iptable rules in there. But even if you have a service that is just a bunch of containers it’s not that easy because you still have to care about start, stop, auto-updates. And that might not be solved by just running Watchtower.
One case of “works on docker” I had was a java service that can’t boot unless it is placed in
/home/<user>and has full access. Otherwise it will fail, and no one knows why springboot can’t work with that, throwing a big fat nested exception that boils down tojava.lang.ClassNotFoundExceptionfor the code in the jar itself.Another fun story was when I tried to setup mariadb without root in a custom user.
I maintained the CHERI LLVM fork for a long time (now I maintain a fork of that). Other folks are still maintaining the fork of FreeBSD for CHERI. I’ve worked on a few in-house forks of compiler things at various points and worked with companies that had in-house forks of FreeBSD.
I think it’s worth characterising them according to why they won’t merge upstream, typically in the following groups:
The first reason happens when you have rare requirements. It’s usually worth engaging with upstream here to see if anyone wants some of the infrastructure for your work. A number of the things that we did for CHERI in LLVM, for example, ended up being useful for AMD GPUs because they also had weird pointer semantics. Folks building managed-language VMs also wanted a stronger separation of pointer and integer types, so we worked with them on some things. Similarly, Juniper wanted stable, parseable output from various command-line tools and it turns out that they weren’t the only ones, so they upstreamed libxo and integrated it with things like ifconfig, so their tooling could just consume JSON or XML output.
The second is common in research prototypes. A lot of these are thrown away (I have a load of these that showed that an idea was not, in fact, a good one). Others die for bad reasons. I’ve seen a few colleagues write papers about some LLVM optimisation but start with an old release and then not have the time to update to trunk and work (occasionally they’re just doing bad science: one abandoned a project because, after getting a CGO paper, they updated LLVM and found that their transform now gave a slowdown when their baseline was less naive). A lot good work in academia is wasted because no one budgets for the upstreaming time. In both FreeBSD and LLVM, I’ve tried to build connections between universities and companies that care about their research and can have engineers work to upstream it (which often involves a partial rewrite, but is usually cheaper than inventing the thing from scratch). The REF in the UK helps because getting things upstream into a widely deployed project counts for more in the impact metrics than simply publishing a top-tier paper.
The third category is often the hardest because it’s very rarely true. Most of the time, the secret sauce is easy for someone else to replicate. It’s also painful because, if it actually is valuable, upstream will implement the same feature in a different way. Now you have to decide whether to make your fork diverge more by ripping out an upstream feature, or throw away your work. If you pick option 1, remember that more smart people don’t work for you than do: the upstream version of the feature is likely to get more engineering investment than yours and so, over time, yours will get worse. Companies that do this well gradually trickle features upstream when it looks like someone else might want to work on them, so they have a small lead but get to share long-term engineering investment.
I would just add, there can be one other reason that I’m aware of, regulatory requirements. If you work in governments/for governments, they can have odd laws/rules, where the code has to exist and be “owned” by someone in country or in organization, etc. Lots of times that means you can’t just fork, you have to create from scratch, which is annoying. Sometimes you can though!
Sometimes it’s easy and it’s literally just a soft fork, where you can get away with just adding a changelog entry, “I own X here”. Sometimes you have to hard fork it for various reasons, and in those situations you usually don’t get to ever play with upstream again.
Though I guess now that I wrote this all out, this could maybe be a sub-category of your third reason.
For corporate deployments, you often need to have an internal soft fork to a repo and then do builds from there, so that the entire source-to-binary flow is on auditable systems. Microsoft does this with all open source that they distribute binaries for and I’ve seen similar flows for internal use elsewhere.
It’s less common now that a load of public CI systems are free for open source, but it used to be extremely common for open source projects to do binary releases from random contributors’ systems (LLVM still does this). This provides a great attack vector for malware: a targeted attack on a single developer can install malware that can then propagate to all users. Big projects typically build on isolated infrastructure (FreeBSD, for example, builds all packages on machines that are not connected to the Internet, so ensures that any malware must be present in the source tarballs, whose hashes are present in the ports tree and are thus auditable later). Newer small projects that provide binary releases will do so with something like Cirrus CI or GitHub Actions where each build runs in a pristine VM with known configurations and so malware needs to be committed to the repo (where it shows up in the git logs if someone looks carefully enough). Cloning the repo and building ensures that any malware that you inadvertently ship must be in the repo and can’t be deleted without your having a separate audit log that shows it was there.
I don’t really view this as forking though, because ideally the copy in your clone is identical to upstream’s. A few places do something like this but carry a handful of back-ported fixes.
How do the source tarballs get into these build systems?
It’s been a while since I looked at the infrastructure, so I’m not sure if this is still the case, but they were exported from a read-only NFS share. If you can compromise a builder, you then had to compromise the NFS server to the outside world. All packages are built with Poudriere, which builds each one in a jail, and also prevents any network access, so you first need a jail escape to get access to the network stack to try to attack the NFS server.
All these attempts to resurrect the “good old days” of the web smack of cargo culting. People are obsessed with the outer forms - Usenet! Blogging! - instead of the socio-economic reality. Back then, writing a blog was the most convenient and popular way of getting engagement online. Now, it’s not. The technology, and most important, the audience has moved on , and the methods of making money from it has too.
Unless I remember wrong, making money was not a concern for the participants of webrings. Only a (by definition) small and noisy subset of people were trying to optimize “engagement”. Webrings are about discovery, not profit.
Same here. Most of the websites I used in 1996 were made by people who were proud that they accomplished something that felt difficult or created a resource they had tried to find but couldn’t and wanted to save others time. Profit wasn’t part of it. A lot of these were hosted on space ISPs made available as part of dial-up plans so cost recovery wasn’t even part of it.
I do think the world has broken that mold though. The amount of stuff that does not exist or is very difficult to find on the web has shrunk drastically. This has reduced the potential for that intrinsic motivation to share useful resources. Similarly, it has become much, much easier to publish content on the web and to create software. This has reduced the frequency of people accomplishing anything that feels difficult and feeling proud enough to warrant building a bespoke website.
That was also true of blogrolls — in the early days. The for-profit blogger was a relatively late development, and one that contributed to the decline of blogs and the rise of social media as we know it.
Eh, lots of people are blogging for fun and making dumb web projects like webrings for fun.
Same was true in the late 90s as well of course
People blogging for money have moved onto silos like Substack and Patreon. The rest of us are doing just fine, and couldn’t care less about “engagement” or chasing an upwards slope on our metrics dashboards.
I’m not against being able to make some money off blogging, but I don’t think the best blogging comes from making it a major source of growing revenue.
Significantly, Substack is marketed as a “newsletter”. The primary alert method is via email.
This is a pitch, not a warning!
The methods of making money have moved in. That is the problem, money making took over everything. Everything became about money, people reach content through a handfull of entry points that will give the spotlight to a couple of content makers per topic. All reachable through the same top list. Anything outside that filter will be relegated to oblivion and eventually die.
YouTube has recently removed the option of uploading videos without ads. Facebook, Instagram et al, have long stopped showing you what your connections are posting in favour or an algorithm that you can’t control nor know that will show you a bunch of stuff you didn’t ask for.
The opportunity for a small website with a stable following base is gone. Everyone gets sent to the big popular content sources instead. There’s also the network effect catalysing this.
If you search a topic on YouTube or Instagram, the results will consist of content producers whose success got to the point of them leaving whatever other job they add and become professional content creators. It became a competition for serious business while before there were amazing online resources visited by millions that were ran by some unknown dude in the Bolivian mountains or in deep in Siberia in his spare time. Things got more suited for the masses, but the focus was taken away from the enthusiastic smaller group who did it out of passion.
The same can be observed in sports. When a sport becomes a successful venture, the participants become business owners. Full with business management made to optimize results at the expense of sportsmanship. But it you follow any less professionalized sport, whenever there is a big international cup, the whole event becomes a genuine celebration of the passion for the sport, with displays of much more honest sportsmanship.
I feel like something millennials like me miss is that computers and the Internet don’t have the same emotional place in the minds of Gen Z. For us, it was the future. Something the previous generation didn’t understand, the next frontier to explore and have adventures in. Now millennials have bills to pay and children to take care of, so there’s much less room for excitement in our lives and the next generation sees computers and the Internet as a corner that’s already taken. Just another tool of the old world order used to exploit them. I wonder how much this picture contributes to the loss of innocence and beauty online.
This is why I treasure lobsters and my local hacker meetup. Not quite relics, but successful echos of what things used to be.
Good. Let them move on. Then we who feel curiosity and passion for the world just for its own sake are among ourselves again. I can do without the salespeople and SEO spam.
I whole-heatedly disagree. Reading blogs was nicer, more convenient and less weird, and it still is.
For quite some time I would have agreed with you, in many different contexts. The internet is filled with articles, videos, etc. claiming “you only remember the good bits”, “you only think it was great because it was the best back then”, “you are only being nostalgic”, “if you would try it again it would suck”.
Just today, co-workers complained about not being able to increase an input field on the website of one of the biggest companies. The other day I tried to contact my bank for the first time, since I needed to send documents I did it online and they have a really low character limit on their input field, so I had to upload my support message as a PDF.
Or look at how easy it used to be to just download a file into a directory. Try that on your phone when you have to.
At some point during the heights of the pandemic when I was being nostalgic I decided to put things to the test. Nope, Usenet is still nice, and nicer than alternatives, nope old video games still are nice, nope, doing stuff off the cloud is… not even still good, but better, than it ever was, using a desktop, better than it used to be, building your own desktop, woah, even the cheapest case feels like workstation quality back in the day, etc.
Managing music on your own system, instead of on some online platform is still so so much nicer, using things like Strawberry.
And none of those things are ever down, unlike CloudFlare, which made a habit of turning their downtime into an ad, or S3 or Google, or Slack, etc.
IRC is still better than Discord to get good, quick responses, and with IRCv3 it even got rid of any downsides.
In general, smaller communities tend to still be higher quality, than.. well, even lobste.rs.
Meanwhile, on big platforms, it’s all 404s, failing registration, logins, weird white pages, lots of JavaScript errors, with a lot of famous apps and application people started to get used to things not working. I mean not so long ago Video Conferences worked most of the time, but despite the pandemic and what not it’s a great big mess. Meanwhile good old Mumble just works.
And then the big news sites. Everyone lying about caring about your privacy, everyone wanting you to pay, acting like it’s donations, pretending to somehow be grass roots. While blogs just through out stuff there for free.
Also I started using Bandcamp for getting my music at the worst possible time I guess.
So in short: If you think that you probably just are nostalgic and think you are only remembering the good bits, go and verify that thought. There is a real chance that it still works great! Some stuff is even better now, BECAUSE the technology moved on, and because the trolls and self-promoters moved on.
I don’t know what you mean by cargo culting in that context. Could it be that you used the wrong term here? Maybe you talk about the circle jerking happening in some of those groups. That’s a thing. But sometimes you just have to dig a bit deeper. Or avoid (a big portion of) Gemini fans.
No, I chose it deliberately.
I sympathize with the desire to move towards a more user-centric internet. I too believe that the current social-media landscape is a morass of user-hostile surveillance and privacy violations.
But many (not all) of the proponents of “the small web” confuse the map for the terrain. They think the reason the early internet was less commercial was that people built stuff themselves, or only the very technical could host or even use a website. And they believe that if they go back to that technical environment, the web will become less commercial. But it (probably) won’t! Because the world has moved on. Everything is on the internet now.
This is in analogy with the real cargo cults, who thought that building replicas of the cargo planes that brought prosperity to islands during WW2 could bring them back.
I believe the best way to deal with internet surveillance capitalism is robust legislation protecting user’s rights to privacy. That’s going to be hard to bring about, and I don’t have the solutions for it. But I do know that if you want voters to demand that, you’ll need to reach them where they are. Shutting yourself in in exclusive networks is probably not going to work.
Interesting. I see it differently. First of all yes, there was a lot more self-build, non-commercial stuff. I was part of some of these things, from interest groups, to private usenet to private for fun game servers and games. People invested their own money and provided stuff they found fun, just like small private clubs.
The other thing is that I see a bit of a dis-illusionment. I don’t see many people that believe they can change it back. Much rather they try to separate to be able to do their own thing. You can still rent a server, a webspace, etc. and just run your own stuff. At least to some degree.
I think yes for some stuff (privacy) legislation is the right way, but for the fact that companies intend to squeeze money out of you. That’s somewhere between hard to impossible to fix. Every now and then a company is created with another goal than making money, but actually to satisfy a need, but typically at some point you end up with people that don’t care and just want to get the maximum amount of money with the least amount of work (which is fine).
Some stuff like having your small community does work. It’s why everyone tells you to join a user group and stuff.
I agree that making the web less commercial is going to happen, but I also don’t think any form of legislation is going to change that.
That, and I suspect there were a lot fewer people, and the people there were very driven to explore and express themselves with the new shiny thing at the time, and were willing to put up with the higher barrier to entry of the mediums available at the time.
Nowadays, there’s a bigger proportion of people with not much to say, and what they do want to say, they can say what they want on a medium they don’t have to maintain (modern social media) - and they like it this way.
It’s a deliberate distancing from “the way things are now”. Sure, you’re missing out on 99.9% of the audience. Lobsters is small (16k users, and far fewer active) because it decided to set itself apart from the norm, in a rather retro way. Yet people find it worth their while to post and comment here. It’s not because we’re driving those millions of ad impressions.
In my experience, when distros package software from other package managers what you typically end up with is dependencies that are years out of date. That is my experience with Ruby and Python deps, and those don’t even need a complicated build process! Compiled languages like Rust would probably be even worse.
As a result, I have zero faith in repackaged deps and never use them.
Those dependencies are only packaged in order to satisfy the application packages that rely on them. I can envision a very successful multi-language apt repository that focused more promptly on repackaging. It would require a massive amount of storage but it would enable a more universal solution and improved resilience through mirroring. It will probably never happen because it would require a huge amount of coordination (on par with Debian) but in theory such a project would allow large orga to offset their Artifactory licensing and operations costs.
When I first heard of MTE I was confused about how it different from CHERI. This MS article was very helpful for me.
Rejoice! For 2023 is the year of containers on macos!
because there is yet another way of running a Linux VM?
I think, with the benefit of hindsight, git should have been limited to the storage data model. It was meant to enable distributed workflows. There are multiple workflow options that can make good use of the data model. The data model is, some would argue, a fundamental reflection of the way software changes. So it makes a good candidate as a common dependency for version control tools to share. Most of the confusing terms, as far as I can tell, come from the limited and kernel-centric workflow support that was built into the early versions. That is compounded by centralized services like GitHub building atop a tool that already chose terms that assumed a much more distributed model of sharing work. If the kernel developers had put the fetch, push, pull, etc functionality into a lkml-dist tool then we would have likely seen GitHub build their own distribution tool that adhered more closely to the contours of their service, reducing at least some of the confusion in terms.
The term “commit” is badly chosen, in my opinion. It conflates the following things:
You can set the state of a repository to a commit in the first sense. If you cherry-pick, you are using commits in the second sense.
Git almost always uses commits in the first sense, and indeed that is their data model behaviour as well.
Cherrypicking changes the meaning because it would otherwise be useless. But that’s something specific to cherrypicking (and base-swapped rebase I assume).
I agree. However, people often tend to think as a commit as a set of changes (as evidenced by some comments here), so I think that proves my point that there is a lack of conceptual clarity.
Empirically I agree: people are confused by this. I am not sure the fault is the word “commit” though. I am curious what you would suggest instead. To play devil’s advocate and defend git, let’s look at the cherry-pick help:
Conceptually, this doesn’t necessarily rely on the concept of a set of diffs, as in a patch file. You can still have “commit” mean purely “committing the entire state of the working directory to disk” and have a coherent concept of cherry-picking: the “change being introduced” is merely the difference between the commit and its parent. Hence cherry-picking is fundamentally contextual and implicitly references two commits. And for that reason requires the
-mflag on commits with multiple parents.Cherry-picking also sets the state of the current working directory. When working with individual commits, I almost always want to also affect the current state in some way. So in that sense they are inherently intertwined. You could call them “revisions” or “changesets” or whatever, but I don’t think that would change the fact that in most workflows they are inherently coupled.
Yes, it does (but in a different way).
Yes, they are. My arm and my hand are also inherently intertwined, but they are very different things.
How so? In both cases IIUC you are just moving HEAD to point to a different commit.
If I asked you raise your hand, I think you would understand that to mean that you also have to move your arm, and the distinction isn’t really that important. It is not a problem in everyday speech that things stand in for other things.
Is it different for Git?
HEADis the name we give to the “current” commit used as the basis of comparison for the working directory state. So we already have different names for #1 and #2. But almost no one says “what commit is HEAD pointing at?”–they say “what commit are you on?” The distinction is there, but most of the time it’s not that important. I wonder if what you’re criticizing is not a feature of Git, but a feature of language itself.The weird thing about
HEADis that it can have different types depending on context. In non-detached state, it’s a reference to a reference to a commit: a reference to the current branch, which itself is a reference to a commit. But in detached state, one of the levels of indirection collapses:HEADis just a reference to a commit.If you check-out a commit, you tell git to set HEAD to the state associated with that commit.
If you cherry-pick a commit, you tell git to compute the difference between that commit and its parent, try to somehow “apply” that difference to the current HEAD, create a new commit and set HEAD to that.
Both can fail if your working directory contains uncommited changes. The latter does a lot more, and it can also fail in a new way: When the contents of a file that is changed by the commit you’re cherrypicking have changed, you get a merge conflict. This is not possible (AFAIK) when checking out a commit.
Maybe you’re right and I am being pedantic. But in general I think it helps a lot when understanding concepts when you have clear names and not conflate things. With the current naming, it is hard to explain to a beginner what a commit is because it an overloaded term.
Overloading the term would be to use the same term for different purposes or concepts. In git a commit is one thing. It is a recording the revisions made to a set of files. You can record them and once recorded you can consume them in multiple ways, each of which has a separate term. The word serves as both a noun and a verb but this doesn’t make it overloaded because the verb form is the act of creating the noun.
The two concepts you referred to have specific names. You used them: checkout and cherry-pick. Those are different actions you can take that each consume a commit (and create a new commit in the cherry-pick case). You can explain the relationship between the working directory and the commit to a beginner quite simply: if you have uncommitted changes to tracked files or even untracked files in your working directory, either stash them or commit them prior to consuming any other commit in any way.
My point is that a commit refers to a snapshot, but the term “commit” is also used to refer to the diff of the commit and its parent.
For example, in github if you click a commit SHA it will show you the diff with its parent, or when you cherry-pick it also considers diffs.
I think this is confusing to beginners (which most people here obviously aren’t) and a more explicit name should be used to distinguish between the two.
How does a commit affect the state of the working directory? It records the staged changes, which come from the working directory. I don’t know if any file changes it makes outside of the .git directory though.
I’ve learned to appreciate the virtue of manually juggling virtualenvs over “automatic” approaches.
If you need to support multiple Python versions, or test against multiple versions of dependencies, “automatic” management of virtualenvs by making them 1:1 with project directories just gets in the way.
Also interesting that the post dismisses pip-tools because it’s a third party tool which doesn’t come with Python and which you have to learn how to use, and then goes on to suggest using Poetry which has the same problem. pip-tools has worked well enough for my needs.
Same here. The “Automatic management of virtualenvs” is a big part of why I find pip replacements frustrating. One of the best features of virtualenvs is that you don’t have to activate them. If you simply run python/pip/etc from their virtualenv path then you are using the virtualenv. I have a handful of defacto project management scripts that assume the virtualenv is in project-local
venvdir (overridable with an env var). It’s a few more pieces but they remain the same across projects so they are easy to build habits around. Most importantly though, exerything is local and explicit. No surprises.I’m a fan of incremental approaches. I’m also a fan of some of the languages looking to replace C++. Overall this talk seems moving in the right direction. Maybe there could be a meeting of the minds in a few years. However this made me laugh out loud:
Is he really meaning to imply that modern C++ is simple?
John Gall’s saying is essentially about solving complex problems step by step, rather than trying to solve everything at once.
However, I think Bjarne is forcing this quote where it doesn’t belong, for two reasons:
Also seems a little misguided. If your language/ecosystem is fully backwards compatible, does it still compile all the old crufty unsafe code? Yes, it does. Did you win anything then? Maybe, if you manage to completely compartmentalize your new stuff (probably want to have linter checks per file/module/subdir then?), and there are probably some benefits to be able to modernize the codebase on the go. But I don’t think a lot of people will do this in earnest, so it’s no real win.
There are two things that Bjarne is quite consistent about:
C++ invented everything first. Interestingly, according to this talk, C++ invented “safety”, although despite long ago inventing safety, C++ hasn’t yet delivered the design and implementation for that invention that it invented first before anyone else thought of that invention that C++ invented. But please wait, because it’s all coming soon, that thing that C++ invented first, long ago.
Anyone that attempts to take a different route than the route envisioned by C++ – including the heretical route of using a different language – is just crazy. In this presentation, the term he used to describe competing ideas is “fantasy”.
It’s a shame that Bjarne has no self-confidence, and takes his lack of confidence out on the rest of the industry. Bjarne’s work has been hugely successful, and that work can and should stand on its own merits. His constant need to tear down and undermine everyone else’s work is infantile and – quite obviously! – destructive.
I think he means to imply that the corollary to Gall’s law, “A complex system designed from scratch never works and cannot be made to work”, applies to Rust. Ignoring the fact that Rust started off as a comparatively simple system that evolved a lot before it reached 1.0. (To some extent by pruning ideas that were unfinished because they were simple place-holders for things that turned out to be too complicated.)
No, if I understand correctly he is saying modern C++ is complex but works, and it evolved from simpler systems that worked (old C++ and C before that).
I think this is trying to place it in contrast with other modern languages like Rust that (while also complex) did not evolve directly from any single existing language.
Well not now, but in a few years’ time what we now call “modern C++” will certainly seem a lot simpler than what we’ll call “modern C++” then!
I’m only half joking. I hate C++‘s complexity but the fact that Gall’s Law uses an absolute rather than a comparison term is just an unfortunate rhetorical exercise – IMHO it should read “simpler”, not “simple”, which is kind of obvious in the book’s original context (Gall wasn’t an engineer, most of the “systems” he talks about aren’t technical systems, and his book is pretty light-hearted in terms of discourse, it’s not a rigorous scientific book).
If one admits that modern C++ works – not the most uncontroversial statement, but anyway :-P – expanding it to cover additional safety idioms isn’t completely out there. For all its tortuous history and shabbiness, C++ does have a long history of evolving features successfully.
This is a misfire. The author is conflating a “bad language” with “a language with a different purpose”.
Shellscript is optimized to call external programs and pipe outputs and inputs between them. And it favours streams of bytes/strings rather than other data types. It does so at the expense of sacrificing other things like quoting or type safety. The people complaining that is a bad language, are the same ones that would complain if their prompt would throw NaN errors or if it would require special syntax for variable expansion or quoting all parameters. The design is such intentionally! The shortcomings were design choices.
Shellscripts are more testable than other languages, as you have for example a prompt shell for it always available. Then even have an error debugging channel built in (stderr).
I hate to be so negative, but I hear such opinions as the ones in this post every other week, and it is pretty much a function of how un familiar with shellscripts people are.
To me the two biggest issues in shell scripts are quoting and continue on error by default. I could maybe see a choice behind quoting (“nobody uses spaces in their paths and this way we get arrays”) but what could be the intention behind continue on error?
It’s not about spaces in tabs, it’s about having the most simple possible syntax to pass multiple parameters, just separate them by spaces.
The intention of continuing on error is to emulate an interactive shell session. But you can change that to exit on error very easily on your scripts if you want.
The use of “load-bearing” also seems quite off the mark.
Given this example, I think “Avoid Homer Simpson Car Shell Scripts” may have been a more apt title :) I believe shell scripts are actually serving us best when they are load-bearing, for accurate definitions of load-bearing. The author seems to think load-bearing means something like “Durable enough to serve at the core” but it actually means something more like “Can efficiently spread the load”. Where is it spreading the load? Down to the foundation. In other words, shell scripts are most useful when they provide enough connective tissue between foundational components to allow each of those components to serve their intended role well.
I see this as relevant beyond just the terms because the language seems to elicit an inverted sense of architectural responsibility:
Load-bearing structures are usually designed simply, with an understanding that they will be extremely difficult to change. I would agree that shell scripts should not be used for a part of your product that will need to be changed a lot. With an eye toward the earlier example, why is retry logic or a killswitch something that needs to change often? The entire arrangement sounds like it was built upside down.
I didn’t have the patience to go through their wall of small text. I always thought “the cloud” meant renting someone else’s computers and letting them take care of the scaling, backups and failovers. Is this just a … on prem server farm?
I view it as a modern version of the mainframe. One big box arrives at your doorstep. You plug it in and everything is already there and you can use it.
Thinking about this some more it is maybe more like Sun infamous DC in a container: https://en.wikipedia.org/wiki/Sun_Modular_Datacenter
Makes sense, since they’re ex-Sun people.
I find the mainframe comparison useful. The things that keep it from being a true mainframe are no longer as important to many – it’s not so important it doesn’t act as a single large computer, or bake more reliability features deep into the hardware (vs. say handling high database availability mainly by failing over). 64-core/1TB RAM/32TB SSD nodes are large enough for a lot already, and most apps are already written as a distributed system where app processes talk to DBs, caches, queues, and storage services–like, that’s the norm even when scale doesn’t require it. (Also, this product has bits like distributed block storage that bring a bit of that “big reliable hardware” illusion back.)
What is like a mainframe, from a business perspective, is:
With the technical aspects of a true mainframe much less in demand today, and the mainframe-like aspects it does have being rare today, it does feel like a modern mainframe in some relevant sense.
I wonder if the potential market–essentially, folks who want to own the resources of at least 16 of these compute sleds and have some real dissatisfaction with using a cloud vendor–will bite at this, or prefer racking Supermicro servers and generic switches or using some other flavor of non-big-3 hosting. The buzz itself might actually be what lets this take off enough to get a durable foothold when similar-seeming things have not. Of course, it also needs to work well in practice, something not really proven yet, and it has to be priced so the business can work!
I also wonder if Oxide or others are going to offer cloud hosting based on this. With what they have today, it’d be very different from what the big providers offer (just as “cloud” offerings from older-school hosting providers are), but I could see selling it on things like the latency/bandwidth advantages of a group of nodes and their storage all being connected to the same top-of-rack switches; you might be able to gin up good benchmarks based on that.
from what I read, it seems like it’s a low-hassle server farm, complete with software and firmware updates. It also seems to be configurable via APIs, similar to the cloud. I imagine you could terraform VMs and resources on it.
Unlike the cloud, you don’t pay a perpetual “tax”, it’s just a one-time purchase. Reading a few articles lately (e.g. DHH) about going on-prem from the cloud, the big argument against going back to on-prem is the hassle, and this seems to address that fairly well.
I think it’s like an “AWS in a box”, in that it’s a big pile of hardware, but with custom software that is programmable via an API.
I want one, of course, because I am a crank.
maybe EC2 in a box, but not AWS in a box.
I believe they have an S3 like blob storage, IAM like capabilities and more. It’s better than “just ec2.”
FWIW, we have an EBS-like block storage system, but we do not yet have an S3-like object store (the economics of bulk object storage on all-flash systems are not fantastic anyway). I think it’s pretty reasonable to think of it as in the EC2 space at this early moment! We’re excited about layering more on top in the future.
(Edit: I guess I don’t really think of IAM or VPC or Route 53 as being separate from EC2, but it you do, we have stuff in those areas also!)
Oh! Makes sense! Thanks for clarifying as someone with first hand understanding!
Fair enough. That is still light years away from “AWS in a box”. Maybe it is “your random VPS provider in a box”.
I don’t have an Oxide Rack brochure sitting in front of me to type out all the features. You might want to do some investigation to evaluate whether it’s just “random VPS provider in a box” or not.
The real point that is being made in this thread is that it’s not a rack that does nothing. It’s a rack that, within hours of being delivered off the truck, can be setup and used to provision production workloads. Their goal is to reduce that time as much as possible.
That is a great feature set. It is however besides the point calling it “AWS in a box”, which what I am trying to say. AWS has hundreds of services, from very low level to very high level. There is no way that you get anything close to that from Oxide. You get the hardware you could build that on, yes. Will it be highly integrated hardware/software and probably quite good? I guess so. I trust their taste. Is this “AWS in a box”? No it is not. That’s all.
That’s probably not an unreasonable way to think about it. One idly wonders if they’ll have a marketplace for service implementations that run on Oxide machines that can cover more of the use cases than “compute + storage + IAM auth”.
EC2+, maybe
Cloud means a lot of different things. That is why nearly every analysis of deployment choices related to the cloud comes with a hefty pile of caveats. The cloud is all of:
The Oxide rack handles the second and it allows you to handle the first and third. Those three together make up the 2011-ish version of AWS. The fourth is a more recent maturation of the cloud offerings. Given Oxide’s young age, they aren’t their yet, but I suspect they could grow to serve a similar role.
Usually the cost of these things is a rental fee. However that is a sales strategy by the cloud provider. The advantage to them is that rental fees present a perpetual option to increase prices and to increase the services used by a customer. Cloud providers could choose to sell their customers a portion of their data center, along with a futures contract for power and network delivery. As growth slows, I suspect we will see relationships like this, along with the associated financialization and arbitrage that goes along with those types of relationships.
In 2011 AWS already had (next to EC2 and S3) EMR, RDS, ELB, SNS, IAM, Route 53, Elastic Beanstalk, SES which are all in the 4th category. I would not call that a “recent maturation”.
source: https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Services
For context, since this appears to be a completely new blog without much background info, the author is the creator of Xfce.
So, a stupid question. In the new cold Wayland world, what’s to prevent running Xwayland rootful and just running all your apps in that? That should support everything that you’d want from X but doesn’t require you to run Xorg directly … right?
If so, then why did we throw the baby out with the bathwater?
You could run Xwayland in a single-app compositor like cage, yes. That’d give you the ability to run on hardware X doesn’t support (i.e. Apple and some other ARM SoCs)
Cage looks perfect for my needs. Thanks for the pointer.
Yes, you could do that. It kinda sorta works. Just don’t use anything modern with that approach, such as GTK4 because it introduces visual bugs for window decorations. I don’t remember the details but it has something to do with GTK4 introducing a new renderer that tries to make more direct use of modern hardware.
The parts of X11 that had to be thrown out revolve mostly around display management and relating visual output to input events. The X11 model for display management was to define a virtual screen and let the video drivers find a way to make the actual displays map to the virtual screen. This precludes any conventional, reliable model for handling changes in display topology, handling heterogeneous displays, vsync, etc.
So if you run X11 program in Xwayland you get to benefit from all of those display management improvements.
The potentially interesting question is whether you can manage Wayland windows with an X11 window manager using this approach. I wonder if it would be possible for a Wayland compositor to delegate window decoration and similar to an X11 window manager running in XWayland. This would require handling reparenting events and probably hooking into the composite / render / damage extension to identify some of the window management operations, but it might be possible. I bet a lot of objections to Wayland would go away if it provided a way for people to run their favourite existing window manager.
It certainly would for me. A Wayland that didn’t upend everything would have been much more welcome, I suspect.
Learned that by coding with a friend I considered a terrible coder.
I worked with him on a lot of fun projects, because we get along well, and he really doesn’t know what he is doing, copy / pasting all other the place, no archi, no design, bad naming… Half of the time he’s not sure what the code is really doing.
And it works.
I noticed how in the end he accomplished more than I did. He didn’t sweat the small stuff, he worked more, way more, as well. He didn’t write unit tests, but he always tested everything manually again and again by playing with the result like a kid.
In the end I embraced the idea.
I wanted to code a contact software because all the ones I tried didn’t do what I wanted. I didn’t, I just used django-admin and called it a day instead of trying to craft some slick UI. I’ve been using that terrible stack of forms for 10 years, and it did the job.
I needed a cli for totp years before any existed, I just fired Python and dumped, in clear text, the seeds in TOML. Took me half a decade to add encryption to it, because symlinking the file from a veracrypt container was sufficient and required little work.
2 months ago I wanted a timer to top up a time budget when I do sport, and consume it when I play video games (https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_…). I just splatted a wall of tailwind regurgitated by chatgpt and pupetted by HTMX. Turns out it was just enough. I show that to my friends that were asking me wtf I was doing with this, and 4 people asked me an account, one a trial for doctors for addiction programs (!). Don’t even have a register form, I hard coded them :)
Wish I told my young self to stop being so obsessed with doing things right or even working on important problems. I never managed to reach “right” in my entire life anyway.
I have had a similar story.
But I switched back and I am very curious about what your take on this is, but isn’t that really boring? At least to me “just throwing stuff together” gets really boring really quickly and that’s why I (mostly) stopped again. It gets to the point where it’s uncomfortably so.
Could be because it’s my hobby too though. I feel like that might be the difference for some people.
I already do the craftmanship thing at work.
It’s a nice break.
Plus I can always clean it up when I feel like it, which sometimes I does.
This is why most of my work is in languages lacking strict typing and without much immediate IDE feedback. I really appreciate types in a lot of situations. However I learn the most from intentionally breaking software by making some small changes and predicting how it will break at runtime and then checking my hypothesis. It’s often hard to justify any particular line of exploration at the time but in sum all of these experiences have repeatedly made me much better prepared than a lot of my colleagues to debug difficult issues. Having a sense for how things run under a lot of different broken assumptions gives me a good distribution of points within the search space to triangulate between.
I dunno man, managed services are more expensive, that’s really the point of them. EKS adds cost, being managed (also, feels a bit misleading to not mention the migration from k8s to Kamal, the in-house tool they developed to manage deployments). You can get better pricing with EC2 spot instances and manage them yourself. Last I checked RDS Postgres costs about 2x an EC2 instance (Aurora even more), and maybe an extra 15, 20% using whatever storage you use on RDS vs EBS. Good for them saving all this money, but DHH doesn’t have to be such a persistent gnat about it. I guess they must be saving that massive tax expenditure, that shocked me when I saw it but made sense.
Persistent gnat… he’s posting to his own blog about progress, and he’s doing it every month or two.
He’s posted essentially the exact same thing 5+ times. His company left the cloud - that’s great, and I’m glad it’s working out well for them. I don’t think we need monthly updates of DHH repeating himself for internet clout.
We have suffered–and are suffering–through the same thing by paid and unpaid growth hackers for cloud vendors. Let him do his thing.
Don’t disagree with that! Though I’d rather see neither here than both :)
A nice feature of lobste.rs is the hide button below posts.
Obviously we all know that we can hide things. Clearly enough people have seen enough of this to agree. People here would generally not like if a less well-known individual rewrote the same post 5 times and continued to repost it here. This situation with DHH is no different.
Gonna push back on this.
Maybe you don’t need his updates, but he needs to work it out and writes about it. That’s to be encouraged, IMO.
I get tired of certain topics, I understand fatigue with things or authors or topics, but IMO it is a net negative to the world to complain about something like this that doesn’t cause any harm.
DHH is a very wealthy CEO writing blogspam to promote his businesses, which are about “collaboration” and getting people to email more “effectively”. He’s not some literally poor random blogger just putting his words out there.
I know who he is. But he’s not forcing you to read this, and as things go this is firmly in the category of Mostly Harmless. It’s, at worst, kinda stale content. It’s perhaps contrarian but not harmful, and I don’t see what purpose it serves for people to complain that he blogs too much. I do see the harm in other people internalizing the idea that “oh, I’ve written about this topic a few times so now people are going to be tetchy with me for doing it again.”
(Source: Have spent a significant part of my career working with tech folks on blogs, and getting past the idea that once they’ve touched a topic they can never do it again for fear of being repetitive is often difficult.)
I read several of them, and my take is that all but the first supplied additional details. All but the first could IMO be summarised as “we’ve continued [project] with [more results] and it still is going well. [More details, including numbers]”, with results/details/numbers on different parts.
IMO this is fine, because he posts it on his blog, it interests someone, and if he hadn’t done it then people would post things like “ah, but did you notice that he stopped posting about how well it succeeded quite early in the project? Draw your own conclusions!!!1!”
Sure there are some people (including you) who didn’t doubt that the rest of the project would be a great success, and for you the additional postings are free of content. But so what? Restrict your blog posting to that which pleases everyone, and you won’t post anything at all.
I dunno, I appreciate high-profile folks speaking out against the “commonly accepted wisdom” or hype. And DHH has always been well-known for being a bit of a douche bag.
Alright, but take a look at the list of features from RDS. It’s not just “apt-get install PostgreSQL” as a service. There’s a very non-trivial amount of engineering effort (and, consequently, money) required to:
And by non-trivial I mean multiple people/year. That’s easily millions (a couple, but still, millions) in personnel costs alone.
Now, of course, you might not need all that. But if you did needed it, but didn’t get it, it might mean all your data is fucked. That kind adds a shitload of grains of salt to the savings proposition.
And this translates to a lot of managed things: kubernetes, object storage, block storage, functions as a service, Kafka, queues, notifications, etc.
That’s what I’m saying. DHH doesn’t need all these managed services because Basecamp etc are all established businesses that understand their infrastructure requirements. If I were starting a business I’d use RDS, but for DHH what was the advantage?
I’ve implemented database thingies both on our own databases and on cloud services, for startups that didn’t understand the 1.0 needs well and had to get something done. You could say: Databases that had to run first in order to learn what they should eventually be.
My impression is that doing it with AWS wasn’t less work for us than doing on our own RDBMSes or on our own NoSQL DBMSes. AWS was quite different in how the hours were spent, in the details of the work. But the amount of work to get our needs going on AWS was quite comparable to that on Postgres or that maligned NoSQL thing whose name I’ve forgotten.
I won’t say equal, because I did it at different companies for different needs. The work was different. But comparable in hour count, yes.
The thing I find missing from this is how to provide backpressure with a latency queue. With a priority queue or a job-specific queue, it is (fairly) easy to say drop X jobs if we know we can’t get to them. But if the only differentiator is latency requirements, we don’t get that (eg. An 8hr latency might be critical but a 15ms latency can be a job that is dropped worst case).
Largely I think it comes down to tradeoffs, I’m not sure you can ever really have one queue strategy to rule them all.
When Rails people talk about background jobs it’s almost entirely just for the sake of moving a slow SMTP conversation out of the middle of an expensive HTTP conversation, welcome emails and the like. There’s not normally a conversation about back pressure or dropped jobs because having way more space than you need (in this case, Good Job keeps its queue in your app’s main SQL database, so you’re probably already over provisioning ) is cheaper than reasoning about what you can afford to drop.
Dropping jobs is not quite the same as back pressure but in the frame of your comment they are both methods of avoiding infinite scale-out. That scale-out is likely informed by metrics and selective back pressure mechanisms can be applied based on the job metrics. e.g. paths that enqueue less critical, shorter latency jobs can return errors to their callers that the subsystem is temporarily unavailable. However, in practice, on the timelines you pose, it would likely be a bug causing some jobs to take much longer than anticipated or a known temporary workload increase in which case a temporary change to the scale-out limit would be approved and implemented. De-prioritizing the longest max latency jobs is what gives you a semi-confortable human-scale timeline on which to react. e.g. you have alarms set for the 4 hr mark on jobs with a max latency of 8 hrs.
Not a lawyer, but I always thought of MIT license as a license, and GPL as a contract. The GPL is like a nation’s constitution, a contract engineered to grant and protect freedom.
The legal idea is that “license” and “contract” aren’t mutually exclusive categories. Loose OOP analogy: license and contracts are interfaces that a deal can implement, not different, single-inheritance parent classes.
Legally, “license” is a “defense” to copyright infringement. If you get sued under copyright, you can beat the case by pointing to evidence you had permission to do what you did. Legally, “contract” means either side, and potentially other people who weren’t part of the agreement but were meant to be benefited by it, can sue to enforce the terms of the deal. That’s different than suing for copyright infringement, which is about someone else copying, sharing, and doing other specific things with a creative work that the law gives you ownership of.
MIT sets a lot fewer rules than the GPLs. But there is a requirement to keep copyright and license notices on the software. There is also a big chunk of disclaimer language at the end, which responds to some defaults in contract law.
I published this read-through tour of the MIT License a while back, if you’d like to have a look “under the hood”.
GNU General Public License. I know it’s just a name, but uhhh.
But uhhh what? It’s a contract. There’s an offer, acceptance, and consideration. Calling a duck a squid doesn’t stop courts declaring it quacks. MIT license is a contract but I’m not a lawyer and don’t see the consideration in it’s terms, just offer and acceptance, so “license” it is. Don’t ask me to explain what a license is - I don’t know, I just know it gives you permission to do something.
The consideration in MIT is you must include the copyright and a copy of the license, right? I don’t see how the two are different.
Not a lawyer, so I don’t know to what extent MIT license terms could provide consideration. Maybe not suing your upstream. Derivative works being shared in return definitely is consideration, though.
I disagree. It would be if the GPL had a condition that you must share derived works with upstream, but it requires only that you share them downstream. This means that there is nothing that upstream receives as a result of the license (they may receive the changes because it’s cheaper to send them upstream than maintain a fork, but that’s an orthogonal concern).
Consideration doesn’t have to be something literally given in return. Definition from Reuters’ Practical Law
Yes, it does; consideration must be something valuable, although it doesn’t have to be material.
In this situation, the typical understanding is that, absent the GPL, there is no permission given for any usage of the code; all rights are reserved according to standard copyright law.
I am not a lawyer, but it feels like a big stretch of that definition to view a constraint on sublicensing (you may sublicense only if you impose the same terms on those that you sublicense to) as a consideration.
I think the advertisement of the licensee as a user of the GPL’d software as well as the advertisement of the availability of the source code could be argued with a straight face to be of value to the publisher. Notoriety is of value after all. Both celebrities and companies have been award damages for harm to their reputation.
edit: it occurs to me now that you may have been pointing to the conditional nature of the GPL. i.e. if the licensee does not distribute then the publisher would not receive any notoriety. However there are a lot of contracts like this in other legal areas such as real estate, mergers, and finance.
This is probably complicated in the US, because moral rights are state law not Federal, but in Europe you have the right to demand attribution does not rely on a contract or explicit license.
I guess that if a promise can be consideration, the promise to publish modifications might count?
I’m not sure that it is, because you’re not promising to release changes, you’re agreeing to be bound by conditions if you distribute and impose those conditions on everyone that you distribute to. You’re receiving a set of rights that’s less than unlimited redistribution, but if I give you £10 you’re not giving me £5 simply because I didn’t give you £15.
The consideration must have some value to the contracting party who is offering the product or service. It’s hard to imagine that any reasonable person would agree that a nebulous possible future modification has any value. For example, what is the estimate of the value? If you are a public company and you go to your shareholders and try to convince them of this value, are you likely to be laughed out of the room? (Yes.)
To put it another way–if you can claim that this promise is consideration, then you can also claim that a promise to, in the future, possibly write and publish a technical article is consideration in exchange for a good or service offered. Which, again, no reasonable person would agree with that.
Software licenses are not contracts. Otherwise why do you have to accept an EULA (End User License Agreement) in order to use software installed on a phone that you have already bought? I.e. you executed a contract with the party who sold you the phone, you paid them the consideration in exchange for the phone, and now you still need to accept a license or else you can’t actually use the phone. Clearly, the license is separate from the contract.
That example makes sense because phones don’t ship with an Android CD and license key. Or I suppose an Android SD card would make more sense, assuming the phone has a slot for one of those.
Because the money you paid was for the hardware. The EULA is granting you permission to run certain software on that hardware. If you don’t accept it, you can still use the hardware but you can’t use the software.
It is not the case, legally speaking, that something which grants you certain rights/permissions to software must be either precisely 100% license and 0% contract or precisely 100% contract and 0% license; it is possible for something to have aspects of both, or to be interpreted differently by different courts or in different situations.
Oh man, this gets complicated because in the US you often don’t actually “own” the hardware in the sense that you can do anything with it. This is part of the reason for the “right to repair” movement. Zod, I love all the complications we as consumers have as a result of capitalism.
You own the hardware. If someone came and physically took it from you, you could report it as theft, for example, and seek to have it returned to your possession. And you can dispose of it as you choose (within the bounds of local laws about things like disposal of batteries and electrical components, of course). And so on – you have the rights normally associated with ownership.
It might be the case that you do not have and cannot easily obtain the tools to reliably disassemble and reassemble the device to a working state, or to replacement parts which will work with the device, but stretching the definition of “ownership” to include a mandate to provide those things is, well, a stretch. Which is one reason why I tend to fight back, hard, against any attempt to make “ownership” synonymous with “easily end-user repairable and manufacturer is required to provide parts and tooling and training in their use on demand”.
That’s fine but I still don’t see any indication that the EULA is a contract. If it is, what are its contractual components?
The only reliable “contractual components” are “a court rules that it is a contract”.
Naming something a “license”, for example, doesn’t bind a court to finding that it isn’t a contract, any more than starting a brutal dictatorship and calling it the Glorious People’s Democratic Republic of Liberty makes that name accurate.
OK, so where is the court ruling that free software licenses like GPL are contracts? Because in the absence of that, I am inclined to give credence to an actual software licensing lawyer: https://lobste.rs/s/rmhnw9/we_were_wrong_about_gpls#c_qmgu2v
There was one out of France a few years ago that did come to this conclusion. Though the French legal system is quite different than the American one so there’s not much value in that decision here.
The article this whole comment thread is about was written by a lawyer.
As C.S Peirce would say, we have now reached the limits of the “method of authority” as a dispute resolver – two authorities disagree. Sooner or later we must move on to the “method of science” – in this case, of performing experiments in the real world (court cases, rather than blog posts or essays or wiki pages) and seeing how they turn out. But I suggest you keep your mind open to the possibility that the result might be, as I said originally, that the answer will be “not 100% license and also not 100% contract but a mix of both”.
Like I said, in the absence of a court ruling, I will look at other sources. And yes, I will look at authoritative sources first, because usually they’re authoritative for a reason. If we are being scientific, then statistically an authoritative source is more likely to know something relevant about the matter.
The answer may be ‘it’s a mix of both’, but a specific one needs to be chosen for the purposes of application to this specific case. And that’s what I’m interested in.
There is no “authoritative source”, though. There are different lawyers with different positions, and you’re just sort of arbitrarily picking one to declare as “authoritative”. On what grounds?
I thought we were talking about authoritative sources because your argument was that we were debating by ‘method of authority’. It’s a matter of who you consider more authoritative, I guess, and I consider Eben Moglen, a free software lawyer and professor, to be pretty authoritative on it. OP less so not so much because I don’t know them, but more because I can’t make heads or tails out of their point.
OP is an attorney well known for writing about software licensing and open source.
Again it seems difficult to find grounds to say “I choose this lawyer as authoritative over all others”. At that point it’s less “authoritative” and more “arbitrary”.
An EULA is a contract. It forms an offer (the software), acceptance (your use of the software), and consideration (the terms of the agreement - access to the software in return for following the terms of the agreement).
https://en.wikipedia.org/wiki/End-user_license_agreement#Comparison_with_free_software_licenses
The reference [5]:
GPL prefers
COPYING.txttoLICENSE.txt