Photoshop 1.0 is from 1988. This was the era of the Macintosh SE [1], the default configuration of which came with two floppy drives, but if you paid a lot more, you could a hard drive that had as much as 40 MB. And it could have an entire 4 MB of RAM.
There are watches today that are 100x more powerful than Macs of that era. Almost anything that was good in a file format from that era would be bad today. Every novel and innovative application feature from Photoshop 1.0 would be seen today as trivial. Many of today's features would have been inconceivable.
If you think you can do better, then I'd encourage you to try. Just start shipping an app with a file format today, get a lot of users, take it through 15 major versions [2], and come back to us in 25 years. Then you can lecture those of us left alive on the right way to do file formats.
It's not that long ago. GIF certainly predates it. I think ZIP does as well, and probably EPS, just to name a few for scale.
None of these does exactly what PSD does of course, so it's impossible to compare them.
A better example is perhaps TeX, which predates it by far, has been extended a lot during the years, and can still render both original documents as well as modern ones.
GIF, EPS, and ZIP do the same thing as they did decades ago. PSD does radically different things. Things that were, as I said, completely unpredictable at the time the format was started.
Consider that one of the challenges to early Photoshop was be doing graphics manipulation that is right at the edge of what the hardware at the time is capable of, I don't think that stuffing a relational database engine between the raw bits and the drive would be helpful.
The challenge needs to add the condition of the app stretching the hardware capabilities so hard that a whole pile of not-so-clean optimization tricks are necessary to get the performance up to the acceptable level.
SQLite versions 1, 2 and 3 have completely different file formats as well as differing semantics especially around typing. Later versions cannot even read earlier versions.
Considering SQLite is only 15 years old and implements a rigorous specification instead of an evolving set of product requirements, you're just over halfway to what he talked about.
When engineering a file format, you have multiple competing priorities you need to balance, such as size of the resulting file, reading and writing efficiency, backward compatibility, etc. Since Adobe didn't anticipate using PSD as a generic file format for graphics applications, it wasn't necessary to design it that way, and I'm sure that other priorities prevailed instead. It's also a pretty old format, probably designed not just once but many times over the years by many people resulting in the inconsistencies the article talks about.
Depending on what you're interested in, I don't think you need to be involved in politics in the Debian world. I've been a minor participant for years and haven't run into much. A huge proportion of decisions, even some fairly complex ones, are made without fanfare. Most of that happens in the discussion threads of individual bugs, on the various collaborative-maintainership mailing lists, at Debcon, etc. There are definitely issues that do have a lot of fanfare, but they are fairly uncommon.
Yeah, that's one of the 1% or so of politically-tinged bits of the project. The ones I can recall from the past few years are: systemd, ffmpeg vs. libav, libjpeg vs. libjpeg-turbo, and whether to ship GFDL-licensed documentation with invariant sections. Fortunately I don't really care about any of those. :-) The systemd debate is the only one of those that's actually a bit interesting to follow imo.
One quasi-political issue that has somewhat more pervasive importance is the general relationship between Debian packages and the Ubuntu packages derived from them, which occasionally is a point of friction if the maintainers have different goals. In most cases it isn't a big problem though, afaict. There are reasonable number of cases where it's even the same maintainer.
In May 2004, a Debian packet maintainer (Eduard Bloch) started to send repeated personal insults to Jörg Schilling after one of Bloch's patch requests against mkisofs was rejected because it was full of bugs.
In March 2006, a group of Debian maintainers started to attack the cdrtools project.
The latter attacks have been based on the fact that cdrtools was licensed under the GPL. As a result, on May 15th 2006 most projects from the cdrtools project bundle have been relicensed under CDDL (giving more freedom to users than the GPL does). At the same time, an important amount of additional code (DVD support code from Jörg Schilling and a Reed Solomon decoder from Heiko Eißfeldt) has been added to the freely published sources.
In summer 2006, the attacks from the group of Debian maintainers escalated and in September 2006, these people created something they call a fork from cdrtools. They soon added a lot of bugs and this way turned the "fork" into a questionable experiment. The last work on this "fork" has been done eight months later on May 6th 2007, then the leader of the attacks stopped his efforts on the fork and instead started to advertize for nerolinux. During the Debian project activity, the source code distributed by Debian was modified in a way that violates GPL and Copyright and makes it impossible to legally distribute this "fork" called "cdrkit". There is no license problem with the original cdrtools.
Ok, we can add that: there was also a debate about a cd-r/cd-rw app, spanning a period roughly 7-10 years ago. I'm not arguing that there has never been an acrimonious debate regarding a Debian package, just that it involves a vanishingly small proportion of packages. So few that I mostly only hear about these things via places like Slashdot (or a comment like this one).
There was no debate; the developer of cdrtools was just an asshole who (for example) refused to let users specify their CD-ROM drive by its actual /dev entry because he thought Linux should use (scsibus,target,lun) to identify devices like Solaris did. Eventually he fucked up the licensing of cdrtools enough that distros couldn't legally distribute it, Debian forked the last legally-distributable version under a new name, and all the other distros switched to their fork.
> Except that most distros DID distributed it UNALTERED, like Slackware, Gentoo, OpenSuSE, Ark Linux.
Only the ones small enough that they don't worry about getting sued. It's not just Debian developers that think there's a licensing issue that means they can't legally distribute it; the FSF and Red Hat's legal department also agree[1], and I believe even the authors of the CDDL (the GPL-incompatible license he's releasing most of cdrtools under) think that he's wrong.
> Only the ones small enough that they don't worry about getting sued
You got it backwards. Precisely only the big commercial distros with mighty legal teams (Debian, RedHat, Fedora) could afford to get away with violating the GPL, and stealing the name of the original project for the fork symlinks. Try to name your toy project something even remotely similar to redhat or debian and you'll be crushed like a bug.
Here I see powerful entities taking advantage of an individual hacker.
""" During the Debian project activity, the source code distributed by Debian was modified in a way that violates GPL and Copyright and makes it impossible to legally distribute this "fork" called "cdrkit". """
""" The GPL preamble (see also Urheberrecht §14 below) disallows modifications in case they are suitable to affect the original author's reputation. As Debian installs symlinks with the original program names and as many people still believe that the symlinks with the original program names are the original software, Debian does not follow the GPL.
GPL §2a requires to keep track of any author and change date inside all changed files. This is not done in the fork.
[...]
GPL §3 requires the complete source to be distributed if there is a binary distribution. The Debian fork tarball does not include everything needed to compile the cdrtools fork (complete source) and Debian does not give a written offer to deliver the missing parts. """
> Try to name your toy project something even remotely similar to redhat or debian and you'll be crushed like a bug.
In Debian's case at least, I don't think there's an objection to third-party projects or forks using names derived from the name "Debian", so long as they aren't actually identically the name "Debian". For example, there is a distribution called "Illumian" which is made up of the Illumos base OS and a Debian-derived userspace.
Besides, I don't really see a trademark issue here. The term "cdr" preexists both of the projects, and is owned by neither of them. A person named their software after a fairly generic derivative of this term, "cdrtools". And now they are complaining that someone else named their software a different generic derivative, "cdrkit"? Do they claim that nobody else should be able to use the prefix "cdr" followed by a noun? Given that they did not even invent the prefix "cdr", that seems like quit a stretch. That's like someone who named their backup product "Backup Tool" complaining that a different product is named "Backup Kit". Sorry, but you don't own the word "backup".
They did that so that scripts which run "cdrecord" or "mkisofs" continued to work, which I'm pretty sure is allowed under trademark law (trademarks don't apply to functional elements - if it wasn't for this, Oracle and Microsoft could kill off any third-party reimplementation of Java or many Windows APIs quite easily). If you run "cdrecord --version" it tells you that it's actually Wodim.
Ok, I agree with you entirely, just a quick response because I was quoting and so have the responsibility to avoid distorting other people's words. This didn't happen 7-10 years ago, that's when it started, but this continued happening until 2 or 3 years ago.
I hope all is clear now.
"""
Ask your Linux distributor to include recent originals instead of broken forks.
Tell them that you like to decide yourself which program you choose. Whether it is the fork or whether it is the original program depends on which package works better.
[...]
The following Linux distributions currently work against the freedom of their users:
Debian, RedHat, Fedora
If you know of other unfree distributions, please report.
The following Linux distributions currently grant their users the freedom to select the better CD/DVD/Blu-Ray writing software:
Why that? AFAIK, they were not allowed to use the name firefox since their version of firefox contains or used to contain unofficial patches and mozilla forbids the use of the name "firefox" in that case.
Renaming was one of the options, dropping the patches the other.
Some do, but they have them Mozilla-approved. Vendor-specific patches are allowed in a product called "Firefox", if Mozilla approves the patches before release. I believe Red Hat is one vendor that does that. Debian won't agree to include a package that needs third-party approval of modifications, though.
That is the 4th criteria of the Open Source definition at work. I think it is a good rule, and makes sense. Mozilla is sharing their code, but doesn't want their name to be used for code they didn't approve.
Docker is based on Linux namespaces.
The first thing which comes to mind is that Docker does not use user namespaces. Hence, the root within Docker is the same root as on the host side. Of course Docker papers over the issue by using apparmor and other tricks but this does not cure the issue itself.
Linux containers (LXC, libvirt-lxc, Docker) are shared kernel visualization. Every single kernel vulnerability will hit you hard.
In contrast to LXC and libvirt-lxc Docker lets you configure a lot of insane setups which are not secure. (But easy to setup)
Also keep in mind resource issues. If you setup your container in a wrong way
it my eat all your available file descriptors, all memory, etc...
(Because it is shared kernel)
Let's face it, the whole technology was not designed for sandboxing, more for
easy deployment of applications.
That said, I really love container and use them a lot in production with libvirt-lxc.
But I don't use them for sandboxing.
Yes, you could queue an at job for every deletion. If you moved the file that approach would break. Also, you'd have to remove that at queue entry if you changed your mind.
Their risk profile is quite different from Transmeta. Transmeta was more of an all or nothing thing. Either they were better at running x86 in which case they easily could capture big segments of the market, or they were not in which case no segment of the market would be interested in them.
The Mill on the other hand can just start with the segment of the market that is the least inconvenienced by having to recompile their code and expand from there. So basically it's easier for the Mill to gain a foothold (build the best cpu for one segment) but harder to climb up from there.
