271–280 of 466 posts
Earlier quoted context omitted.
I'd like to think this post is an exaggeration.
Unfortunately not there are a lot of developers can only use phpmyadmin or thier CMS's gui - and from what I am told being able to code basic sql joins is not something you can take for granted.
Earlier quoted context omitted.
It isn't, but so aren't dozens or hundreds of other commands you encounter when working with the command line. I managed to memorize a few invocations of tar (I listed them in another comment) but, for instance, I very rarely create a new archive so I'm never sure what flag I need to use. Part of the problem is that each command line utility has its own flag language, and equivalent functions often have different let…
You don't have to be a sysadmin to be comfortable with command line tools. If you want to fully utilize your *NIX system you have to learn how to use that shit, it really isn't that hard. (I'm a developer.)
Sequences of commands sometimes get pasted into a conveniently-located text file; if I find myself repeating the operation I might turn it into a script, a shell function for my .zshrc, or an alias.
Just 10 minutes ago: mysqldump [args] | nc -v w.x.y.z 1234 nc -v -l 1234 | pv | mysql [args] (after an initial test that showed adding "gzip -1" was slower than uncompressed gigabit ethernet.)
Earlier quoted context omitted.
It's just automated copy-pasting of commands you don't understand from the internet, which is something everyone who runs Linux (and is not a wizard) does all the time. It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. Unfortunately, this has never been a priority in Unix-land as far as I've gathered.
It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. But it isn't all that hard to understand a clean Unix. I have never copied or typed a command that I don't understand. One problem may be that most Unices these days is not as clean anymore as, say OpenBSD or NetBSD. E.g. the recent X stack, with D-BUS, various *Kits, etc. is qui…
This because they want to retain their ability to shop for off the shelf hardware, while getting away from a platform that has proves less than functional for mission critical operations (never mind being locked to a single vendor).
What seems to be happening is that there is a growing disdain for power users and "admins". The only two classes that seems to count are developers and users, and the latter needs to be protected from themselves for their own good (and developer sanity).
Earlier quoted context omitted.
http://www.askartsolutions.com/iso9001training/Identificatio... ISO9001 often turns into its Dilbert parody of bureaucracy, but the core ideas are sound: if you have some sort of failure of production, it's useful to know what went into the production process and where it came from. So in the case of deploying images, then yes: you get repeatable copies of the image. Provided you know where the image came from . Imag…
Have you ever seen it implemented in a way that added value? I agree that in theory ISO9001 makes sense, but it's been a slow-motion disaster everywhere I've seen it actually tried.
Earlier quoted context omitted.
But then there's a circular dependency because the GPG key is retrieved by the bash script that is wget'd.
It doesn't have to be circular. The script is secured by HTTPS (and hopefully has the key embedded in the script itself?) which can then retrieve the installer and verify it using the key.
The whole security, whether GPG is invoked or not, relies on the security of the HTTPS connection alone.
If the HTTPS cannot be trusted alone, then everything is lost as a compromised HTTPS connection can be used supply both a comprimised GPG key and a compromised package, or, indeed, anything at all that is legal to `| sudo bash`...
And HTTPS security boils down to:
1. The difficulty of altering (or exploiting privileged position wrt) the global routing table to setup MitM or MitS scenarios.
2. The difficulty of obtaining a valid looking certificate for an arbitrary domain.
Any situation where a government actor is the adversary poses intractable challenges to both 1 and 2 above. (And before you say NSA/GCHQ would never care about XYZ, consider China...
Earlier quoted context omitted.
I don't get this. Tar isn't that hard. x = eXtract files from an archive f = File path to the archive c = Create a new archive from files v = print Verbose output z = apply gZip the input or output That's 99% of common tar right there. The remaining one percent is: j = apply bzip2 to the input or output (I admit, j is a weird one here, though that has made it stick in my memory) --list = does what's on the tin --excl…
It isn't, but so aren't dozens or hundreds of other commands you encounter when working with the command line. I managed to memorize a few invocations of tar (I listed them in another comment) but, for instance, I very rarely create a new archive so I'm never sure what flag I need to use. Part of the problem is that each command line utility has its own flag language, and equivalent functions often have different let…
Earlier quoted context omitted.
> The value of debian is not that they package (or repackage) everything into deb files but that they resolve versioning and dependancy conflicts, slip security fixes into old versions of libraries (when newer version break API/ABI), and make it possible to integrate completely disparate software into a system. Maven has exactly the same capabilities as deb does - you can depend on versions, depend on a range of poss…
> No, it's just the opposite. All the dependencies and project structure are right there in declarative XML. It's what make should have been. When make was written most machines would have just exploded at the sight of a typical build.xml, and downloading tens or hundreds of packages from anywhere was simply out of the question. Also, 'dependency' means something completeley different in make as opposed to maven - I…
Sure. But the notion of doing things declaratively existed (Prolog predates make by five years). And the biggest difference between make and the scripts that preceded it is that it's more structured, with a graph of targets rather than just a list of commands.
If you add the ability to reuse libraries of targets (something that sort-of exists via implicit make rules), restrict targets to something a little more structured than random shell commands, and - yes - add the ability to fetch dependencies (including target definitions) from a repository, you end up with something very like maven.
I agree that many of these convenient setups are embarrassingly sloppy, but it's the sysadmin's responsibility to insist on production deployments being far more rigorous. No one can tell you how to build hadoop? Well, figure it out. Random Docker containers being downloaded? Use a local Docker repo with vetted containers and Dockerfiles only. I don't even allow vendor installers to run on my production systems. My e…
>> No one can tell you how to build hadoop? Well, figure it out. I get the impression that several people working on debian couldn't work this one out!
Earlier quoted context omitted.
> Programmer must be aware of which version of what API implemented with what version of package or library he using and explicitly assert and maintain these requirements, like all the very few sane software projects (git, nginx, redis, postgress) do. Except that when you're doing anything that looks like an actual end-user application (as opposed to infrastructure), you end up using dozens of libraries which themsel…
> as the only reasonable way for giving a service application to people to deploy on their machines Take a look how git or nginx compiles from the source on any machine imaginable. There is absolutely no fundamental problem with ./configure; make; make install .
> There is absolutely no fundamental problem with ./configure; make; make install.
The fundamental problem is incompatible versions of dependencies. Arguably it's in linux's dynamic linker rather than a problem with configure/make. But if you need to run something that depends on libfoo 2.3 and something else that depends on libfoo 2.4 on the same machine, you need something like docker.