Erm.... software development is exactly a use-case where widescreen hurts. Want more lines of code, not less. Width doesn't matter, it's rare for lines of code to be longer than 80~120 characters.
It's worth noting that systemd's NTP and DHCP implementations are purposefully as simplistic as possible. The NTP daemon (systemd-timesyncd) is only a client that keeps a clock synchronized to a server, it cannot behave as a server itself. The DHCP daemon (systemd-networkd) is meant only to handle a wired network connection on a single interface, the sort of thing that a server or maybe a desktop computer would want; more complicated network setups can ignore this functionality and use any number of the pre-existing network configuration methods Linux already had.
It still has no official modding support. Mojang bought Bukkit and hired its team over a year ago, but they still keep it an independent project and not the official mod API (think how CentOS is now owned by Red Hat but still has a social/corporate firewall between RHEL and CentOS devs).
As for being written poorly in Java, it was original just some dumb idea that Notch had to remake Infiniminer, and his Random Java Project #56 -- he already had mild internet fame (albeit nothing compared to his post-Minecraft fame), but this particular game had just enough potential to keep it moving. He didn't make it to be very performant in the first place, Java was just familiar and convenient to him.
Sure, 5-10 are pretty okay but it's really basic kindergarten-level bantering.
I don't think any rational person would ever say "Gee, I felt like cheating, stealing, and killing today, but I'm so glad we have those COMMANDMENTS to tell me not to!"
It used a file called --linux-.--- in each directory. In a way, it was better backwards-compatible with FAT/MS-DOS than even VFAT was.
I did some disecting of how they worked a while ago expecting that I'd reimplement it with FUSE, which I never got down more than a couple trivial files (like the base-32 representation stuff...). I'll just put up the format notes on a Gist if anyone's interested:)
It was rather common back in the Windows 9x days to still be using floppy disks, of which were formatted with FAT12. LFNs were fully supported on it too for this reason.:)
These days, kids will relate every first-number-before-the-dot version increase with Chrome and Firefox.
Quite honestly, their versioning schemes wouldn't even be all that bad for Linux, the "3." or "4." are totally meaningless numbers anyway. At the same time, it provides some buffer zone for people that expect X.Y schemes represent significant new versions whenever Y is increased.
TeXmacs is pretty great; the UI has a lot of issues (menus are a mess, keyboard shortcuts are really unusual, too many damn preferences...), but the core functionality is solid.
As much as the joke doesn't really apply to Trek movies, it doesn't really apply to Windows versions either.
Far as I'm concerned, on the DOS side, anything before Win95 was worthless. Windows 95 was alright for what it was, and I avoided W98 like the plague because of its instability. ME never saw enough adoption for it to have actually meant anything; and it really wasn't as bad as people make it out to be. Windows XP garnered a lot of flack for not being anywhere near as good as Win2K, but it went on for years without Longhorn being released and a couple service packs made it decent enough. Vista also has a reputation it frankly doesn't deserve, and W7 is just a renamed Vista.
Yeah and GTK+ 2.x was API/ABI incompatible with GTK+ 1.x, pretty much setting an expectation that the whole thing will be overhauled approximately once a decade. So whenever GTK+ 4.0 is out, your 3.x apps likely won't just compile+run as-is in the new version, but there's no reason you can't have all the older libraries installed at the same time.
The tried-and-true method of just keeping around stuff like zip/tar.gz/exe files in a directory of every binary released should be fine... never delete the old releases.
For a pure open source solution, using a git repository is good enough for the same purpose, Mercurial includes a very mature bidirectional Git importer/exporter (their concepts are all mappable to each other, there shouldn't be any downsides to it). Git is missing the opposite direction, but someone can always step up and allow Mercurial to be cloned from Git.
10. Windows lacks a good, advanced file system like ZFS.
NTFS is a pretty decent filesystem. It doesn't have flashy features and it's not hip, but it gets the job done, it's reliable and you know what... those are the two primary considerations for a filesystem. At least for most people.
Considering that NTFS has absolutely no way to guarantee data integrity, the reliability claim is dubious at best. The guy's talking about ZFS; NTFS is already pretty poor compared to traditional-model stuff like XFS or ext4, but for as far ahead as ZFS is with checksums, redundancy, copy-on-write, etc, NTFS is stone age.
Linux has never had a good or stable GUI environment. Ever.
I beg to differ. GNOME 2.32 was about as close to perfect as a desktop has ever been achieved.
(GNOME 3: you can still get the old UI back, but it's hidden as being a possibility. The 3.x Panel does work better with screen resolution changes (what games often do) since applets are snapped to left, center, or right instead of being freely placable (it's a good thing actually).)
Slashdot Mirror
Erm.... software development is exactly a use-case where widescreen hurts. Want more lines of code, not less. Width doesn't matter, it's rare for lines of code to be longer than 80~120 characters.
It's worth noting that systemd's NTP and DHCP implementations are purposefully as simplistic as possible. The NTP daemon (systemd-timesyncd) is only a client that keeps a clock synchronized to a server, it cannot behave as a server itself. The DHCP daemon (systemd-networkd) is meant only to handle a wired network connection on a single interface, the sort of thing that a server or maybe a desktop computer would want; more complicated network setups can ignore this functionality and use any number of the pre-existing network configuration methods Linux already had.
There's no real point in using it if you can't even trust it does what they say it does...
I really really really hope you're just trying to troll.
It still has no official modding support. Mojang bought Bukkit and hired its team over a year ago, but they still keep it an independent project and not the official mod API (think how CentOS is now owned by Red Hat but still has a social/corporate firewall between RHEL and CentOS devs).
As for being written poorly in Java, it was original just some dumb idea that Notch had to remake Infiniminer, and his Random Java Project #56 -- he already had mild internet fame (albeit nothing compared to his post-Minecraft fame), but this particular game had just enough potential to keep it moving. He didn't make it to be very performant in the first place, Java was just familiar and convenient to him.
I have both / and /boot on ZFS on Linux.
Sure, 5-10 are pretty okay but it's really basic kindergarten-level bantering.
I don't think any rational person would ever say "Gee, I felt like cheating, stealing, and killing today, but I'm so glad we have those COMMANDMENTS to tell me not to!"
It used a file called --linux-.--- in each directory. In a way, it was better backwards-compatible with FAT/MS-DOS than even VFAT was.
I did some disecting of how they worked a while ago expecting that I'd reimplement it with FUSE, which I never got down more than a couple trivial files (like the base-32 representation stuff...). I'll just put up the format notes on a Gist if anyone's interested :)
https://gist.github.com/chungy/7852622
It was rather common back in the Windows 9x days to still be using floppy disks, of which were formatted with FAT12. LFNs were fully supported on it too for this reason. :)
These days, kids will relate every first-number-before-the-dot version increase with Chrome and Firefox.
Quite honestly, their versioning schemes wouldn't even be all that bad for Linux, the "3." or "4." are totally meaningless numbers anyway. At the same time, it provides some buffer zone for people that expect X.Y schemes represent significant new versions whenever Y is increased.
It requires a system capable of VT-x/AMD-v and enabled as well.
I don't know about you, but I never stopped that practice. You can still make Windows 7 look like Windows 2000 (it's a massive improvement IMO).
TeXmacs is pretty great; the UI has a lot of issues (menus are a mess, keyboard shortcuts are really unusual, too many damn preferences...), but the core functionality is solid.
As much as the joke doesn't really apply to Trek movies, it doesn't really apply to Windows versions either.
Far as I'm concerned, on the DOS side, anything before Win95 was worthless. Windows 95 was alright for what it was, and I avoided W98 like the plague because of its instability. ME never saw enough adoption for it to have actually meant anything; and it really wasn't as bad as people make it out to be. Windows XP garnered a lot of flack for not being anywhere near as good as Win2K, but it went on for years without Longhorn being released and a couple service packs made it decent enough. Vista also has a reputation it frankly doesn't deserve, and W7 is just a renamed Vista.
Yeah and GTK+ 2.x was API/ABI incompatible with GTK+ 1.x, pretty much setting an expectation that the whole thing will be overhauled approximately once a decade. So whenever GTK+ 4.0 is out, your 3.x apps likely won't just compile+run as-is in the new version, but there's no reason you can't have all the older libraries installed at the same time.
GTK+ 2.x apps aren't magically breaking and GTK+ 3.x apps won't magically break either.
Why keep that in version control though?
The tried-and-true method of just keeping around stuff like zip/tar.gz/exe files in a directory of every binary released should be fine... never delete the old releases.
For a pure open source solution, using a git repository is good enough for the same purpose, Mercurial includes a very mature bidirectional Git importer/exporter (their concepts are all mappable to each other, there shouldn't be any downsides to it). Git is missing the opposite direction, but someone can always step up and allow Mercurial to be cloned from Git.
NTFS is a pretty decent filesystem. It doesn't have flashy features and it's not hip, but it gets the job done, it's reliable and you know what... those are the two primary considerations for a filesystem. At least for most people.
Considering that NTFS has absolutely no way to guarantee data integrity, the reliability claim is dubious at best. The guy's talking about ZFS; NTFS is already pretty poor compared to traditional-model stuff like XFS or ext4, but for as far ahead as ZFS is with checksums, redundancy, copy-on-write, etc, NTFS is stone age.
NonCommercial is going to make it useless as a textbook. It can't even be included in, for example, Debian or other Linux distributions.
Thanks, you're right. Misread it on account of not being awake for long :)
Oracle never supported OpenIndiana, it's a distribution of illumos (the OpenSolaris fork).
I beg to differ. GNOME 2.32 was about as close to perfect as a desktop has ever been achieved.
(GNOME 3: you can still get the old UI back, but it's hidden as being a possibility. The 3.x Panel does work better with screen resolution changes (what games often do) since applets are snapped to left, center, or right instead of being freely placable (it's a good thing actually).)
I forgot. Slashdot doesn't do Unicode :D
We are the Knights who say NI!
Incompetent evil is still evil.