2,224 karma · joined April 8, 2022
Since this is actually env calling bash first, not docker, this should just be a Bash script. You can still feed the Dockerfile to docker build via STDIN. But you'd gain the ability to shellcheck the Bash, the code would be easier to read, write, maintain, add comments to, etc. You could keep the filename the same, run it the same way, etc. The way they've done it here is just unnecessarily difficult.
Ha, found some (kind of) evidence:
Radiowave Effects on Humans - March 28, 1980 / T. Neil Davis (https://www.gi.alaska.edu/alaska-science-forum/radiowave-eff...)
One reason the question is unanswered is that the energy absorbed by a human from radio waves depends upon the relationship between the size of the human and the frequency of the radio waves. Just as a TV antenna of the right length and orientation picks up the best signal (the most energy) from a transmitted wave, so it is with a human being. It appears that the cranial cavity of a mammal will resonate at specific radio frequencies determined by the size of the brain cavity. At these resonant frequencies the human head will absorb vastly more radiowave energy than it will at other nearby frequencies.
An adult's head will resonate at a frequency between 350 and 400 MHz (megahertz). Being smaller, a child's head will resonate at a higher frequency, somewhere between 600 and 850 MHz. Since each individual may have his or her own resonant frequency, a particular frequency radiowave might affect one person more than another. Consequently, testing on humans--even if people are willing to let this happen--can be rather complicated.
I have the same laptop (using it right now). You can add another 8GB, even though the specs say you can't. (thanks, lenovo...) The big limitation seems to be CPU, despite having an i7-6500U in this one. Opening Google Maps makes the machine crawl, but most other sites don't have a problem. It's definitely not speedy but it is functional with about 100 tabs open.
The main reason I want to replace it is to use a USB-C docking station, have real graphics support ("hybrid" graphics is crap in Linux), and have more than 5 hours battery life. Otherwise it's kind of amazing how well it's working after 7 years.
Even though it's technically "heavy" for a modern laptop, it actually feels easier to pick up and carry around than lighter laptops. The corners are angled/sloped so that they're very easy to slip a hand around, and the case is sturdy held in one hand even when open (thanks to the case being half-metal, half-plastic). Way easier to move around than my Macbook. A great example of how design makes a big difference to usability.
You could copy the files onto a RAM disk on another computer and call that a backup, but you'd probably be nervous about the computer shutting off and losing your backup. Copying files to a remote disk may have the exact same probability of failure. You don't know until you investigate and calculate the probability. And if you haven't tested the recovery recently (or ever), you don't know the probability of recovery.
The probability of failure or recovery has to consider all eventualities. For example, it's now common practice for cybercriminals to attempt to erase backups of data in a ransomware attack. But it's also possible for people to accidentally delete backups. A proper backup should defend against these eventualities in order to increase the probability of a successful restore.
If the purpose is to simplify, then you would want to remove the components that add complexity, but here instead of removing them, we've simply changed them, and removed some of their useful functionality. Complexity remains but in a different shape.
My criticisms are personal, in that it feels like the page is trying to be willfully deceptive, and that's annoying.
"Stop building slow, complex, fragile software systems"
....but do use data replication over a network.
"Safely run your application on a single server"
...ignoring the fact that this really has nothing to do with "safety" in terms of either security, redundancy, reliability, or durability.
"No-worry backups - Continuously stream SQLite changes to AWS S3, Azure Blob Storage, Google Cloud Storage, SFTP, or NFS."
....ignoring the fact that that's a copy, not a backup. (If you think those are the same thing, you should read a book on backups)
"Runs as a separate process so you can integrate into existing applications with no code changes."
So now you've got to manage two apps, not one? I thought this was simpler?
"Object storage is cheap so there's no need to waste money on additional servers."
If the whole idea is to remove pieces to make something simpler and more reliable, wouldn't you want to use Serverless? Since that's literally zero servers? (CGI apps are the 2000s version of serverless, but way simpler... yet nobody is talking about CGI either)
As to your assertion ("idea that they could say whatever they wanted in whatever community they wanted and not expect any reactions"), I don't think I or anyone else said that or suggested it. Sounds like a sweeping generalization designed to reinforce an opinion you want to believe. But it also seems like you drank the kool-aid a while back, so I'm pretty sure I can't influence your opinion.
You know what makes a great chef? Mise en place, technique, and taste. Organization, preparation, skills, and that indelible knowledge of what looks and tastes good and why. The best chefs don't focus "on process" or "on content", they have to do both, or the dishes will either be inconsistent or mediocre.
If you're part of a cult, and you're not allowed to eject someone from the cult, you can at least ignore them or walk away from them when they talk to you, if you don't agree with what they say/do. It's a way for the members of the cult to reinforce the ingroup's behaviors without having overt power over the group. For other people watching this behavior, it reinforces the need to align themselves with the larger group, to avoid the same fate.
The first rule of fight club is you don't talk about fight club.
Which I'd wager is due to over-reliance on search engines. The net is stuffed to the brim with useless bullshit designed to steal eyeballs, so finding anything somebody published two decades ago is now impossible. Internet Archive is useful if you already know what website used to exist, not so useful if you don't.
Whatever happened to that website that was a combination of blog + archive of exploit POCs? Wasn't it called PacketStorm? I just tried to find it with two search engines and came up empty. That would've been an ideal place to track down old techniques and news.
You'll never know for sure what shell is the default, so write your scripts to a minimum shell family, and encode the name of that shell family in the shebang.
- A Bourne shell
- A C shell
- A POSIX shell
- A "modern" shell, like Bash, Zsh, Fish, Osh
#!/usr/bin/env sh
# ^ should result in a Bourne-like shell, on modern systems, but could also be
# a POSIX shell (like Ash), which is not really backwards compatible
#!/usr/bin/env csh
# ^ should result in a C shell
#!/usr/bin/env bash
# ^ should result in a Bash shell, though the only version you should
# expect is version 3.2.57, the last GPLv2 version
#!/usr/bin/env dash
# ^ you expect the system to have a specific shell. if your code depends
# on Dash features, do this. otherwise write your code using an earlier
# version of the original shell family, such as Bourne or POSIX.
Different shells have different implementation details. For example, Bash tends to skew toward POSIX conformance by default, even if it conflicts with traditional Bourne shell behavior. Dash may try to implement POSIX semantics, but also has its own specific behavior incompatible with POSIX.
In order to get specific behavior (like POSIX emulation), you may need to add a flag like --posix, or set an environment variable like POSIXLY_CORRECT. For shells that support it, you can also detect the version of the shell running, and bail if the version isn't compatible with your script.
Here are some references of the differences between shells:
- Comparison of command shells[1]
- Major differences between Bash and Bourne shell[2]
- Practical differences between Bash and Zsh[3]
- Fundamental differences between mainstream \*NIX shells[4]
1. With a savings plan or on-demand?
2. Keeping one instance on per developer indefinitely, or only when needed?
3. Shared nodes? Node pools?
4. Compared to what other instance types/sizes?
5. Spot pricing?
Moreover, if your whole stack (plus your test suite) doesn't fit in memory, what's the point of buying an extremely expensive laptop? Not to mention constantly replacing them just because a newer, shinier model is released? If you're just going to test one small service, that shouldn't require the fastest MacBook.
To test an entire product suite - especially one that has high demands on CPU and RAM, and a large test suite - it's much more efficient and cost effective to have a small set of remote servers to run everything on. It's also great for keeping dev and prod in parity.
Businesses buy MacBooks not because they're necessary, but because developers just want shiny toys. They're status symbols.
Sorry, but it actually does make sense in multiple ways.
Firstly, the core purpose of cybersecurity in the C-suite is to ensure the bottom line. System resilience is not the priority, the priority is the stock price. That means that it's way more important to triage an issue, collect evidence, determine impact, and see how many ways you can legally hide evidence or manipulate the situation to deny you ever even had a security incident. The quieter it stays, the smaller the impact to the bottom line. Keeping compromises to a minimum, improving UX, meeting modern best practices, etc are like the farthest things from their minds. And the people who run the company dictate what these teams prioritize. So to "the company", there's a good reason why they focus on their own thing.
Secondly, security is really frickin' hard. Humans are not great at being masters of many things. You need a specialist who understands security well, and has the tools, and training, to do security-specific things. Why do you think "platform teams" (aka the new-new-sysadmins) exist and we don't just have developers build their own platform? Because there's ops crap in there that devs will never know, and shouldn't need to. Humans work more efficiently when they can focus on specific things, keep context switching to a minimum, and maximize their specific knowledge to a small domain. That includes security tools, practices, policies, etc.
Thirdly, because of the competing priorities of security, and the specialization needed to truly do it well, you have to have a "security process" that people who aren't security experts can follow. You also want a "security process" because processes in general are useful tools to keep things working correctly. Even "security people" should be following a "security process". And there needs to be "security people" to come up with the process (ideally in collaboration with the other teams).
What you don't want is bad process, or bad teams, or bad special snowflake solutions, etc. You want it to be supportive of other parts of the business, rather than a hindrance. That's what DevOps is all about - getting people to collaborate together, enabling self-service, increasing efficiency, improving quality, reducing waste, etc, etc, etc. You can do that with security too, and it doesn't mean you have to get rid of your security teams/solutions.
There have been seven (7) 0day exploits in Chrome this year (that we know of). Know how many CVEs there were for Chrome in total in 2023? Two-hundred and forty (240). That's impressive. And this is the browser people brag about as being secure.
If the platforms continue to be a major source of income for many people, then those people need to petition their elected representatives to force the platforms open. The OS has to give you a choice of browser, so the smartphone should have to give you a choice of app store.