Genuine question: How do you believe one should learn these semantics? This is more something I've been pondering myself recently, because I agree with you that the foundational knowledge for our work in any tech stack is usually the most important for understanding higher abstractions. But with so much to know it feels impossible to 'know it all' so to speak especially if you wear more than one specialized hat. Then beyond that even if you're only trying to learn just the foundations how do you know what those foundations are if you're not already inundated in that stack?
This is mostly just my personal ramblings, but I'd be curious other peoples viewpoints on this.
And so the Google web crawler had come across this page and happily visited each and every one of those links.
That’s when I learned about the importance of using forms with POST requests for certain actions instead of using links that send GET requests.
And then some years later someone told me about this thing called HATEOAS and about RESTful APIs and that actually there are different HTTP verbs you can use other than just GET and POST. Like for example
DELETE /path/to/file
As for your question about how someone is supposed to learn that these days?
Ideally whatever web development tutorials or courses or books they are using would at some point tell them about the different HTTP verbs that exists, and of how and when to use each of them, and crucially to tell them about bad consequences of using GET for anything that has side-effects like logging out a session or deleting a file.
This can be complex sometimes, but in case of HTTP methods specifically, it's hard to imagine how one can't know about this.
You learn HTML (and see a mention of "POST" method); or read HTTP primer (and see reference to methods) or open browser inspection window and see prominent "Method" column, or see the reference in some other place. You get interested and want to look it up - say wikipedia is often a good start [0] for generic part. And the second sentence of description says it all:
> GET: The GET method requests that the target resource transfer a representation of its state. GET requests should only retrieve data and should have no other effect.
IMO it's very understandable to not know about this sort of thing starting out. Everybody was new once, and it's much easier to get motivated to build cool stuff than to read about all the fine details of all of the technologies we're using. I say, go ahead and take the shortcuts and build some cool things in a maybe sloppy way as long as the traffic and stakes aren't too high. Then, once you've got something cool built, take some time every now and then to seek out and read about more of the details of some of the systems and tools you're using.
While it may not be quite the same answer you're looking for, I'd suggest the OWASP, and at least their top 10 for sure. Learning about SSRF may not have stopped this behavior (it's coming from the authenticated browser), but if you're doing CSRF checks you won't get logged out by random links on other peoples sites, and that whatever logged you out was a legitimate action.
Exactly. And ditching the "move fast and break things" mindset. Learn your craft and embrace the learning process. Always be curious about how the stuff below your layer works, fundamentally. Recurse on searching for the seminal works that defined those layers.
We (the industry) have built up so many layers upon layers and frameworks designed to make things easier that it just seems to attract newcomers to software engineering with this mindset that all it takes is to start with the sample-app for a high level framework, hack on it with trial and error until it does something they want, and then take to social media with proclamations of "Look! I built a thing! You can hire me to build your thing now!"
To add to this, it feels to me like SWEs have the biggest egos as well without a related checking mechanism. In other engineering disciplines getting something wrong very often comes back to you as the engineer, in SWE it feels like there are so many abstractions people like to point fingers at instead. "It's not my code that's the issue, its X implementation's fault" the amount of times I've heard something similar to this is too often.
100%. I don't know what to call it other than coddling, but there was very, very, very, little true responsibility. Safety in the herd: don't let the people who got the stuff done get too up in their heads about it, via their design had issues at the end of the day, and conversely, if I did deliver something of low quality, it was someone else's design that was the problem.
All the firing BS in from mid-2022 in this industry was poorly motivated, and a lot of the initial wave was used for settling political scores, and there's a lot still there. But I hope in the long run it engenders a stronger sense of needing to have some sort of shared reality and responsibility.
You might be right that SWEs have the biggest egos compared to other engineering disciplines. When I've worked with mechanical and electrical engineers, that was the case.
But where I work now, the biggest egos are easily the people around the SWEs - especially architects and product owners. Is that not the case where you work?
It's comments like these that make me realize we've gone full circle in the convenience life cycle. Pre-steam when you wanted to play your game you would have to download system specific dependencies to ensure your game could run on your specific system. Most of the time these came pre-packaged with the installation files, but rarely you would just have to 'figure it out' when your game crashed upon opening. Time to spend hours trolling some forums to find the answer to the random byte string you were presented. If you are someone who only plays one game, then perfect, once you got that single install figured out you're good to go. Want to play another game? Time to figure it out again. Today you go to steam, click play, and steam just 'figures it out' in the background. Not to mention never having to deal with proper save files again because you swapped systems or the numerous other features that gamers have cried about for years. I'm not saying you should use steam if you hate it as much as you seem to. It's just really ironic to me that if all you're looking for is 'double-click the game and go' you don't want to use Steam. My favorite part of your comment is "Steam, you run other programs. That's all you do. You're bad at your job." because yes, all it does is run other programs, and that's why it's so GOOD at its job. You simply can't or don't want to understand what it's actually doing.
oooh, thanks for the context! I've installed and run... maybe 50 games over the past 30-ish years, and every single one has run right out of the box. I'm on a Mac, so maybe that's the difference?
So the meta-conversation is: why was (is?) installing and running a game so difficult? Why did game-makers suck at that, creating a billion-dollar opportunity for Steam?
So unironically the answer to your first question is yes. After reading your other comments in this thread now I completely understand your perspective, and I hate Apple even more for it. Apple literally coddles their users to the point where they have created likely millions of users like yourself. You expect everything to conform to the Apple way, instead of you adapting to the ecosystem you are in. Apple specifically forces developers of their ecosystem to follow specific rules when it comes to installation, UX, dependencies, the whole 9 yards. It's why a lot of game developers simply avoid Mac entirely as a platform. Because it takes a tremendous amount of effort to conform to Apples silly requirements, for less than 1% user base on average (from a game developer perspective entirely).
But then you may ask, well if Apple has such a standard for everything, why not everything just conform to that and we make everything easier... It's not that simple see: https://xkcd.com/927/
It's not that installing and running a game is 'so difficult' it's that you're expecting it to be as simple as everything else you do in your Apple ecosystem. Because that's how Apple wants it. It's entirely a perspective issue forced upon you by the ecosystem you use.
The end result for all this is all the jokes we see about children expecting everything to be touch screen, or having no idea what to do with a controller when they see one. As humans we adapt to our environment, but if we're always forced into the same systems, we start to expect every system to work that way and we stop adapting.
Agreed, this feels like someone put an argument about tabs vs spaces at the top of the description for an editor. Like yes, you will have to choose whether to use systemd, but the argument for or against systemd doesn't feel like it belongs here in a list of 'minimalist user space programs/services'. From my perspective the only lens you can view this through that's even closely related is that systemd doesn't follow the Unix philosophy of 'do one thing and do it well', but that's not exactly an argument for or against minimalism. I'd argue that almost everything systemd brings to the table in a default setup are all things you'd need anyway, minimalist or otherwise. They're just all handled by one overarching service, which I think is the real argument against systemd.
>Agreed, this feels like someone put an argument about tabs vs spaces.
This is not true. That is an aesthetic discussion. People dislike systemd because it is insanely bad software.
>I'd argue that almost everything systemd brings to the table in a default setup are all things you'd need anyway, minimalist or otherwise.
That is legitimately insane. No, you don't need the things systemd brings to the table. Systemd replicates multiple parts of what your systemd already does. E.g. it replicates the fstab by providing mount units. No normal user needs those, fstab works just fine, yet for some reason they include it anyway. Systems now can also boot your system, again it is repeatedly implementing already existing functionality. Same for DNS, surely you absolutely need an init systemd to handle DNS...
That is why people dislike it and why it is obviously not "minimalist" in any way, replicating already existing functionality is the exact opposite of
>They're just all handled by one overarching service, which I think is the real argument against systemd.
No. The argument is that systemd is really bad software which repeatedly reinvents already existing OS features in its own way, even if those features are near unrelated to an init system.
I don't care about "Unix philosophy", no system should be designed like systemd. People complain because it is badly not because it violates some barely defined rules about what "Unix should be".
The people who hate systemd are effectively a loud minority, and for some reason always seem incapable of discussing the supposed issues with it without resorting to hyperbolic statements like “legitimately insane”.
I absolutely did include explicit problems with systemd in my post. And I wasn't hyperbolic, what systemd is not explainable by any rational thought. If you want to tell me why your init system should also be an fstab and a DNS provider go ahead.
I criticize systemd because for months my full time job was dealing with it. I suspect the minority of systemd haters are actually people like me, who actually had to do non-trivial things with it and realized how bad it is, if you actually have to do things with it.
Hating systemd is sort of a joke in certain Linux circles, where "Unix philosophy" and "minimalism" are tossed around. I don't really care about that discussion. Systemd is awful by any philosophy which aims to provide good software, for almost anything you can fill the word "good" with.
A DNS resolver, NTP client and boot loader as part of the init system does seem to be a bad idea, no?
All of them are worse than what they are replacing - more limited and more buggy. Sometimes because they are just new, sometimes because the authors don't know what they are doing. In any case, why switch?
Regarding "part of", there's a nice motte and bailey argument from systemd that they are absolutely not parts of it when talking to critics, but when it comes to shipping and using them, they are.
It was especially bad when udev "moved in with" systemd, there were promises to keep it working without systemd. These were swiftly broken. Assuming good faith from that crowd is a mistake.
Fortunately, there is a fork of udev that works without systemd, and you know what, it's not even a difficult one. So what were the strong technical reasons for adding the dependency?
This is mostly just my personal ramblings, but I'd be curious other peoples viewpoints on this.