Plato thought that the best form of government would be rule by philosopher-kings.
I'm with Plato: the general population is too stupid for a democratic system. Unfortunately we have not yet reached Culture levels of technology so it's the best option we have at the moment.
Can you imagine having to sit through SIX YEARS of a case? The last time I was summoned for jury duty it took three days until I was dismissed from selection and I was already pissed at everyone involved for wasting my time.
Supporting distros is easy. Most package management boils down to "./configure ; make ; make install" then you create a glorified tarball of the results. For a complex application you may break it into multiple glorified tarballs then stick them into a repository (yum, apt, whatever) and generate some metadata on the packages using a simple command (it's literally "createrepo./" for RPM distros). This is all basic stuff and can be done in an afternoon.
It's also important to know your market. You say "supporting 80% of the linux user base", but for most apps that is not the goal. If you're writing a game, for instance, you're only interested in desktop users. You can hit 80% coverage by targeting Fedora and Ubuntu alone. If you're writing server side software to be used in datacenters then you can hit 80% by supporting RHEL, CentOS, and Debian/Ubuntu.
In this particular market, RHEL and CentOS are all we need. Our customers are already using them. Adding support for additional distros is possible, of course, and fairly trivial to do. I have worked on other products which supported RHEL, CentOS, Fedora, Debian, Ubuntu, Slackware, and Solaris simultaneously.
I am writing an installer for an enterprise telco carrier application today. It's actually very simple. The installer logic is as follows:
1. Verify that the OS we're running on is a supported one (RHEL or CentOS) 2. Verify that some required hardware is present and configured correctly 3. Configure a yum repository (5 line text file listing where to find RPMs) for our application RPMs present on the CD 4. yum --enablerepo=companyname install productname 5. From this point on yum and RPM work out all of the dependencies and our application gets installed. We can even pull updates from our repositories connected to the Internet (access restricted based on known client source IPs). This is all done using the default distro package management routines.
The real problem in Windows is that all of these software packages have their own independent (and potentially broken) update mechanisms. One thing that modern Linux distros get right is centralized software updates. My Ubuntu laptop has a dialog box waiting for me most mornings that details any software updates it would like to install, and whether or not they are security related. I could tell it to do it all automatically but I like reviewing the changes before I install them.
Oh, and not to start a flame-war, but ASL is the "Ebonics" of sign language. Learn Signed English, instead. Yes, they're different.
Sorry, but I'm actually completely not interested in languages. I took ASL because it was considered a foreign language by my high school (this was 15 years ago) and I didn't want to bother with anything that had a complicated grammar. You have interested me in Signed English somewhat, though. Even with my passing study I'd noticed that ASL was somewhat simplistic (the English equivalent of "me go mall" rather than "I went to the mall") and I'd always wondered if that was a symptom of the language itself or the teacher.
According to my ASL instructor, lip readers are rarely more than 50% accurate. Which makes me wonder about the alleged capabilities of this software, honestly.
Speaking as someone who spends a lot of time in data centers: A serial adapter is pretty much mandatory. Why don't you have one? Worst case scenario you can buy a USB one and keep it in your laptop bag. Best case scenario you should have an entire serial console server and just plug your device into that. Serial is the lowest common denominator: works on servers, switches, firewalls, load balancers, PDUs, and damn near everything else. Serial is awesome.
In California we have the CHSPE, which is a High School proficiency exam you can take once you're 16. I took it and left HS two years early, went on to a community college then a 4 year and got my degree. For me it was a great option since I was essentially just twiddling my thumbs in HS.
More complex environments may need more complex treatement. The organization may decide to identify mission-critical services that must not be interrupted, or special procedures to follow for particular systems. That's all to the good.
The more mission-critical a service is, the more important it is that I should be able to reboot individual components of it. In an ideal case I should be able to walk into my datacenter and put a bullet through any arbitrary component without anyone noticing.
Those who do not perform scheduled reboots of their servers do not know whether their servers will come back up properly after unscheduled reboots. How often have you seen someone add a service to a machine which becomes a critical part of your infrastructure then they forget to add it into the RC system?
Yes, after I RTFA'd it became clear that the 13000mph figure is likely a muzzle velocity. I am totally not going to guess at drag coefficients and do the integral to figure out what the actual delivery height and speed would be.
Gems would be a godsend. I have a repository with 86 packages in it for one of my clients who runs a RoR app, most of those are gems. Most of them are easy to package thanks to gem2rpm, but there are a few which are a PITA and required me to patch the source, hack the spec file, or both in order to get them to install correctly. Even so, we end up losing half of the advantages of a modern packaging system since we need to re-build any updated versions ourselves.
You want SELinux. It's enabled by default in, for example, Fedora.
From the description I do not believe that it would have helped in this instance, however. The screensaver was distributed as a system package which would have allowed the package's install runtime scripts to set everything up with whatever privileges the author desired.
Slashdot Mirror
I'm pretty sure they already have.
I'm with Plato: the general population is too stupid for a democratic system. Unfortunately we have not yet reached Culture levels of technology so it's the best option we have at the moment.
Can you imagine having to sit through SIX YEARS of a case? The last time I was summoned for jury duty it took three days until I was dismissed from selection and I was already pissed at everyone involved for wasting my time.
RTFS. Cell signal, not wifi.
lololol RT @adamofgreyskull /dev/sda5 /tmp nosuid,noexec,nodev 0 0
Supporting distros is easy. Most package management boils down to "./configure ; make ; make install" then you create a glorified tarball of the results. For a complex application you may break it into multiple glorified tarballs then stick them into a repository (yum, apt, whatever) and generate some metadata on the packages using a simple command (it's literally "createrepo ./" for RPM distros). This is all basic stuff and can be done in an afternoon.
It's also important to know your market. You say "supporting 80% of the linux user base", but for most apps that is not the goal. If you're writing a game, for instance, you're only interested in desktop users. You can hit 80% coverage by targeting Fedora and Ubuntu alone. If you're writing server side software to be used in datacenters then you can hit 80% by supporting RHEL, CentOS, and Debian/Ubuntu.
In this particular market, RHEL and CentOS are all we need. Our customers are already using them. Adding support for additional distros is possible, of course, and fairly trivial to do. I have worked on other products which supported RHEL, CentOS, Fedora, Debian, Ubuntu, Slackware, and Solaris simultaneously.
I am writing an installer for an enterprise telco carrier application today. It's actually very simple. The installer logic is as follows:
1. Verify that the OS we're running on is a supported one (RHEL or CentOS)
2. Verify that some required hardware is present and configured correctly
3. Configure a yum repository (5 line text file listing where to find RPMs) for our application RPMs present on the CD
4. yum --enablerepo=companyname install productname
5. From this point on yum and RPM work out all of the dependencies and our application gets installed. We can even pull updates from our repositories connected to the Internet (access restricted based on known client source IPs). This is all done using the default distro package management routines.
The real problem in Windows is that all of these software packages have their own independent (and potentially broken) update mechanisms. One thing that modern Linux distros get right is centralized software updates. My Ubuntu laptop has a dialog box waiting for me most mornings that details any software updates it would like to install, and whether or not they are security related. I could tell it to do it all automatically but I like reviewing the changes before I install them.
Sorry, but I'm actually completely not interested in languages. I took ASL because it was considered a foreign language by my high school (this was 15 years ago) and I didn't want to bother with anything that had a complicated grammar. You have interested me in Signed English somewhat, though. Even with my passing study I'd noticed that ASL was somewhat simplistic (the English equivalent of "me go mall" rather than "I went to the mall") and I'd always wondered if that was a symptom of the language itself or the teacher.
According to my ASL instructor, lip readers are rarely more than 50% accurate. Which makes me wonder about the alleged capabilities of this software, honestly.
Can it find my keys?
Speaking as someone who spends a lot of time in data centers: A serial adapter is pretty much mandatory. Why don't you have one? Worst case scenario you can buy a USB one and keep it in your laptop bag. Best case scenario you should have an entire serial console server and just plug your device into that. Serial is the lowest common denominator: works on servers, switches, firewalls, load balancers, PDUs, and damn near everything else. Serial is awesome.
In California we have the CHSPE, which is a High School proficiency exam you can take once you're 16. I took it and left HS two years early, went on to a community college then a 4 year and got my degree. For me it was a great option since I was essentially just twiddling my thumbs in HS.
The more mission-critical a service is, the more important it is that I should be able to reboot individual components of it. In an ideal case I should be able to walk into my datacenter and put a bullet through any arbitrary component without anyone noticing.
Those who do not perform scheduled reboots of their servers do not know whether their servers will come back up properly after unscheduled reboots. How often have you seen someone add a service to a machine which becomes a critical part of your infrastructure then they forget to add it into the RC system?
Sort of makes you feel better about the human race, doesn't it? :)
Yes, after I RTFA'd it became clear that the 13000mph figure is likely a muzzle velocity. I am totally not going to guess at drag coefficients and do the integral to figure out what the actual delivery height and speed would be.
13,000 mph is a stable orbit at a height of 11803 kilometers. That's a bit less than two Earth radii.
This is a myth.
Gems would be a godsend. I have a repository with 86 packages in it for one of my clients who runs a RoR app, most of those are gems. Most of them are easy to package thanks to gem2rpm, but there are a few which are a PITA and required me to patch the source, hack the spec file, or both in order to get them to install correctly. Even so, we end up losing half of the advantages of a modern packaging system since we need to re-build any updated versions ourselves.
You want SELinux. It's enabled by default in, for example, Fedora.
From the description I do not believe that it would have helped in this instance, however. The screensaver was distributed as a system package which would have allowed the package's install runtime scripts to set everything up with whatever privileges the author desired.
And what would we do with this super strength? Personally, the heaviest thing I ever need to lift is the occasional DB server.
I call that CFengine. Except I don't have to a mouse, so that's even better.
Their roadmap states that the 1.0 milestone is "full SVG 1.1 support".