Or it could just honor fstab since that has always been the correct way to specify mounting a filesystem.
Not really. If systemd is monitoring the mounts, which it does because executing mount -a at some arbitrary point during the boot process is not the best way to mount the required filesystems during boot, it makes sense for it to give priority to it's own config files. Anyway, I don't know the exact nature of the problem, but I suspect it is because systemd mounts filesystems before/etc/fstab is parsed. If you try to mount an already mounted filesystem, it will just get ignored. This is the default behavior of the mount command and has nothing to do with systemd.
I see no reason that should need to touch system logging at all other than adding a log entry if it has to take action.
Agreed. It doesn't need to, but the two activities are logically connected. Technically, journald is a separate service from systemd that is designed to work well with systemd, and it collects a lot more information than your basic syslogger. It is not required, though, and you can continue to use syslog if prefer it.
It's a massive, complicated, and very poorly behaved substitute for a simple, robust, and well behaved program. And it's not just a regular program, it is (if used as intended) a critical system component that will take your entire system down when it goes wrong.
Not at all. Don't substitute you not understanding a system with complicated and poorly behaved. There are careful design decisions and planning of systemd. You may not agree with them, but that doesn't make it wrong. Systemd is increasingly more popular for a number of very good reasons. It has become a freedesktop.org standard. You could start by reading this, http://0pointer.de/blog/projec...
But since you probably won't, let me just say this. Serially executing a bunch of arbitrary shell scripts has got to be the worst possible way to design an init system. The fact that it works doesn't make it good. First of all, each script is code. Second, no script is aware of any other scripts presence, although intrinsically linked to and dependent on those other scripts. Third, a typical shell script is >100 lines of block logic to implement the equivalent of "service start". A configuration file for systemd for a single service can often be less than 10 lines and very easy to read.
I know I know, none of that matters, it is too "massive" and "complicated".
Maybe, but I don't know when "back when" was. A distribution has to make some choices about how to package things and that necessarily removes choice from the end user. Most basic example of this, the package manager. You can't really choose which one you want and which format. The distribution chooses the package manager, you choose the distribution. Or better yet, initmodutils, replacing insmod with modprobe. It's funny how users seem to fine with that, but when the distribution makes a decision they don't like, then it is being "shoved down your throat."
I'm not sure if you are arguing it is better for the computer or better for the human reading it. I dunno, I prefer human-readable plain text files over an easily parsable "complex syntax", especially for something as basic as the init system. That's why I (mostly) hate xml as a configuration file format (*cough* launchd *cough cough*). It is good for making guis, but terrible if you ever need to edit the file by hand at a terminal.
When it takes over file system mounting, including hiding most mount points
I can see how this is annoying, especially when you don't know what is going on, but mounting filesystems is an integral part of the startup process and therefore should be managed (in part) by systemd. It was manged using the old sysV scripts too btw, so it is consistent as far as init systems go. The difference with systemd is it actually knows what a filesystem is and that it is different from a service, so it can manage and monitor them accordingly. What this means is that filesystems associated with booting (root, swap, dev,...) are now systemd entries instead of/etc/fstab entries. Once you realize this, it is not that hard to manage. And/etc/fstab does still work, of course, for filesystems you want to manage yourself. There are reasons you might want to create systemd entries for those too, though. Automounting, for example, is handled much better with systemd than the old autofs route that we had to use before.
and breaking silently if there are perfectly valid mounts in there which it happens not to like
That is either a bug, or possibly a conflict. Again, I can see how it is annoying, but if you have an/etc/fstab entry that wants to steamroll a systemd entry, it is understandable that systemd will try to stop that from happening. The correct fix in that case would be to edit the systemd entry to match the changes you are trying to make with the/etc/fstab entry.
When it takes over system logging
So, systemd doesn't just start/stop services, it also monitors them and can be configured to take certain actions depending on what happens to a particular process. So, needless to say, logging is kind of inherent to the whole thing. Correct me if I'm wrong, but I don't think it "taking over logging" is your real objection, but rather the way in which it does its logging. Instead of splitting things into separate text files that are managed by their respective daemons, systemd collects all this information and stores it in a standardized, indexed way within its own file. This is a design decision, and with all design decisions there are tradeoffs. In this case you are sacrificing the ability to just cat/grep individual text files for the ability to filter and have other processes able to monitor the log files, as well as some benefits for auditing and security. I definitely prefer text files because I don't manage complex scenarios, but I can also see how journald is critical for certain enterprise infrastructure. If you don't like journald, you can install syslog-ng. You just have to make sure it doesn't trample on journald (ie: it has to listen on the journald socket instead of/dev/log). I believe CentOS 6 is configured this way (journald+syslog-ng), so it is not that unusual or hard to do.
Never used SMF, but systemd is quite a bit better than launchd. The configuration files are all plain text. The major difference from a configuration point of view is that instead of writing a script, you just specify executable information, dependencies, sockets, etc, in a config file. That's it. Doesn't seem like such a big deal to me and in many ways seems quite a bit better than sysV.
Hate to break it to you, but when you install a distribution, you have a lot of software "shoved down your throat." It is what a distribution is, after all, and has been the case since forever. The maintainers decide what functionality is in the base system, what packages are installed in meta packages, what versions, what optional features to compile in. The only way around it is to use a source distribution like gentoo.
First, I have to ask, what is wrong with systemd? It actually works quite well.
That said, even with systemd (and upstart), sysV scripts are supported for backwards compatibility because quite a few system services do not yet have a systemd startup script. I have not looked at the networkmanager or policykit packages, but I am almost certain the dependency is only because of the startup script. If you grab a sysV script, you won't need systemd to install them. This will likely require some voodoo with the package manager, though. My recommendations in order of ease,
1) use --force to ignore the dependency (this might great problems if you ever have to repair the dpkg database, though)
2) grab another package from some other distro and install (with alien if need be)
3) tweak the package yourself to remove the dependency (wouldn't be hard to maintain wrt updates, etc)
4) compile from source and install (create your own package for maintainability)
Why do the media companies keep making this tired claim? 1 bazillion downloads doesn't equal 1 bazillion lost sales because not everybody would have bought the special edition dvd with holographic cover art. Wait, what were we talking about again?
And why would efficient use of screen real estate be applicable only to netbooks? I would like the majority of my screen to be used by what I am currently working on, not a bunch of user interface clutter.
Also, note this statement in your own Wikipedia reference, "Canonical announced it had engineered Unity for desktop computers as well and would make Unity the default shell for Ubuntu in version 11.04."
Uh, ok, like another reply says, how often do you need to look at every application on your system?
Here are a few scenarios that come to mind.
1) Need to run a specific application.
a) Click the Dash, type a few letters, click the application or,
b) Click the Dash, click the categories view, filter by category, click the application or,
c) Find your application, drag it to the Launcher for quick access
2) Need to see all "Internet" applications.
a) Click the Dash, click the categories view, filter by category
3) Need to launch an application, but don't remember it's name, only something vague about it.
a) Click the Dash, type a few letters (not necessarily the beginning of the name), go aha!, click the application
4) Need to find a document that you were working on, but don't quite remember the name or where you put it.
a) Click the Dash, type a few letters (not necessarily the beginning of the name), go aha!, click the document
On the classic interface, 1b and 2a are possible. The rest are not. So while Unity may require a couple more keypresses in some comparisons, it seems more capable and flexible to me as a desktop.
Now ads are annoying, yes. I don't like that. Thankfully you can disable it. I also don't like the global menu, which this article is about. They seem to be changing it.
Except that they aren't. Because X has not had true network transparency for over a decade. It does the same screen-scraping that RDP does, but just in a horribly inefficient way. X doesn't even have proper security, which is why remote sessions are tunneled through SSH. If you think that is efficient, you are probably the type of person that runs an IPSEC tunnel through the Tor network for fun just so you can check your email. The only advantage X has going for it is convenience. Remoting just works with no extra configuration required, just an X server (on the client, yay confusing X terminology). There are much better ways to do remoting. We can do better for linux, and Wayland provides the opportunity to engineer something good, without needing to hold on to legacy baggage.
This was my first reaction too. However, reading the article (I know, I must be new here) clears it up,
There are two reasons birds might fly in a V formation: It may make flight easier, or they’re simply following the leader. Squadrons of planes can save fuel by flying in a V formation, and many scientists suspect that migrating birds do the same. Models that treated flapping birds like fixed-wing airplanes estimate that they save energy by drafting off each other, but currents created by airplanes are far more stable than the oscillating eddies coming off of a bird. “Air gets pretty darn wiggy behind a flapping wing,” says James Usherwood, a locomotor biomechanist at the Royal Veterinary College at the University of London in Hatfield, where the research took place.
Just as aerodynamic estimates would predict, the birds positioned themselves to fly just behind and to the side of the bird in front, timing their wing beats to catch the uplifting eddies. When a bird flew directly behind another, the timing of the flapping reversed so that it could minimize the effects of the downdraft coming off the back of the bird’s body.
“From a behavioral perspective it’s really a breakthrough,” says David Lentink, a mechanical engineer at Stanford University in Palo Alto, California, who was not involved in the work. “Showing that birds care about syncing their wing beats is definitely an important insight that we didn’t have before.”
And from the actual research article,
Many species travel in highly organized groups. The most quoted function of these configurations is to reduce energy expenditure and enhance locomotor performance of individuals in the assemblage. The distinctive V formation of bird flocks has long intrigued researchers and continues to attract both scientific and popular attention. The well-held belief is that such aggregations give an energetic benefit for those birds that are flying behind and to one side of another bird through using the regions of upwash generated by the wings of the preceding bird, although a definitive account of the aerodynamic implications of these formations has remained elusive.
We conclude that the intricate mechanisms involved in V formation flight indicate awareness of the spatial wake structures of nearby flock-mates, and remarkable ability either to sense or predict it. We suggest that birds in V formation have phasing strategies to cope with the dynamic wakes produced by flapping wings.
So, it's a little bit of a behavioral science study...is saving energy why they do it, or is saving energy just a happy consequence? And it's also a bit of a mechanism study...to gain the most aerodynamic benefit requires adjustment of the wing and position to meet the updrafts, so how well do the birds do this?
If you're telling me it doesn't work (don't have one to verify myself), fine, sounds like it needs a bug report. KMS has nothing to do with anything. Using an older AMD driver doesn't preclude you from using a new and updated distribution. Ubuntu has had "nvidia-legacy" packages for similar reasons for years. Not sure why you don't like the radeon driver, but https://launchpad.net/~makson96/+archive/fglrx. It says 13.10 and beyond will be more of a pain, but 12.04 is supported now and will be until 2017.
I think what he means is that the network transparency feature of X11 involved sending X primitive commands over the network to be rendered on the remote X server. With the modern desktop environments and toolkits this doesn't happen. Yes, you have a remote display, but it is sending pixmaps and screen buffers over the network instead of X primitives. So it is slow as hell and doesn't take full advantage of the local (client) hardware.
That's almost, but not entirely, true. ALSA had kernel-level software mixing (dmix) that any application written to use ALSA could benefit from. As long as I used 100% ALSA applications, it worked fine. The problem was, as you say, not all applications would support ALSA. They would use OSS and rely on the bridge device between/dev/dsp and the/dev/alsa devices as a compatibility layer. The mixing would still work if you were using 1 OSS application and 10 ALSA applications, but not if you were using 2 OSS applications. The solution was a higher level sound-mixing daemon that could abstract the hardware layer away from the applications. Again, the problems as you state were incompatible daemons between KDE and GNOME, until finally PulseAudio comes along which does two things. It abstracts the hardware much further (ex: it supports network sounds devices), and it hooks into everything (OSS, ALSA, ESD, artsD, Phonon), so any application written to use any sound subsystem will go through PulseAudio first. I'm not sure PulseAudio is the best solution, it has issues with latency and so forth. But getting all disparate software projects to agree on a single sound subsystem is harder, so it was never done. I believe there were a few attempts to get either ESD or artsD into a Freedesktop spec, but that never went anywhere.
a) This isn't radio. Spotify's user base isn't that large, so 2% isn't as much as it sounds. b) The more songs you have, the better chance you have of somebody listening to it. So if you have only one song, yeah that might be hard to hit. But if you have 40, it is easier. c) Big caveat to my calculation: I don't know what Spotify's sliding scale is. For 2% of the user base, the payout may be significantly larger and thus the required number of plays to make a reasonable income smaller. d) Spotify's revenue comes from ads, so it makes sense to split it up based on how popular a song/group is. If only 0.01% of the user base is listening to your music, you can't expect Spotify to give you a large piece of the ad revenue generated by their service.
The entertainment industry, whether it be music, tv/movies, or sports, is about popularity. If you can't boost your popularity, it just isn't going to work out, regardless of Spotify's business model. That is the reality.
Ok, let's stop and think about that for a moment. If you are a serious enough musician that you intend to do this professionally, let's assume you have put up at least 1 album, which for the sake of argument is about 10 songs. Spotify has 24 million active users, http://press.spotify.com/us/information/. So to make the 400,000 play cut, about 2% of Spotify's user base has to listen to at least one of your ten songs per month. That does not seem unreasonable to me. If you can't make that cut, the professional music gig probably isn't going to work out for you, sorry.
You are right, they should do more work on the study and get more data. But any questions about statistical significance and/or experimental design should have been addressed at the peer review stage. And then after that, there is even a final decision by the editor-in-chief to actually publish the study. Bad science or no, the study made it through. It happens all the time. See the arsenic in DNA controversy, or the huge argument over a generalized mechanism for antibiotic killing by reactive oxygen species. I can pick up papers from the 80s where they didn't purify their enzyme well enough and determined the wrong kinetic mechanism. What was the response to all of these? Different groups performed different studies and refuted the original findings. Sure there was a lot of clamor as well, but ultimately it was the experiment that settled the issue.
Calling for retraction in the absence of any kind of experimental evidence is not the way to handle this. I am not surprised the authors refused. Retraction has a huge stigma associated with it, and if they weren't deliberately fraudulent, they don't deserve it. The scientific community can scorn all they want, but it means nothing without experimental evidence to back it up.
It was only a few years ago, but I guess it has already left the public memory. A group of scientists rush to a hasty conclusion because they want to make a big splash. Science publishes it because they like controversy. A large flurry of criticism from the scientific community, but ultimately a number of papers get published refuting the original findings. We can ask the question...should it have been published? A lot of people think no, but it is an illustration of the scientific process.
Sometimes bad science gets through peer review. Sometimes the science is not particularly bad, but the experimental design was missing something. Maybe they had an impurity in one of their reagents that they weren't looking for. Lots of incomplete or just outright wrong studies pass peer review and get published. But this is something the scientific community accepts as a part of the process. If you strongly disagree or suspect the conclusions of an article, do the experiments and publish a counter-study. Otherwise, you are free to make a lot of noise and be annoying, but then you might go the way of James Watson.
but I just went to a training course to learn about a high-end enterprise product that runs on top of Linux
Uh huh, sure. Unless your "high-end enterprise product" runs on a 10 yr old copy of Slackware, what you've written is complete baloney.
Compare this to a sample PowerShell pipeline "Get-Process -Name 'n*' | sort -Descending PagedMemorySize"
As I'm sure you had to learn how to use Powershell, you will likewise have to learn how to use the command line in linux. And when you do, you will know what -e does for the most important commands. Btw, the majority of common linux commands have long-name switches along with their shortened counterparts (ex: cp -a vs. cp --archive), as well as quick --help pages to refresh you if need be.
Rail is optimal for regional distances. The faster the train, the larger the regional area it can serve. Ex: 200 mph makes serving a 600 mile area practical. Much faster than a car. Competitive with a plane when you consider time through security, comfort, etc. I used to take the Amtrak back and forth from home when I was in college. Driving might have been a bit faster, but not cheaper. And the train was a lot more comfortable.
For cross-country trips, that is the domain of air travel. No need to try to solve every problem with the same tool. Get rid of all of the crappy regional jets that are loss leaders anyway and replace with a nice train system. Bonus points if you can seamlessly connect between a flight and a train trip.
Does simply not wanting to pay more for something mean there is a shortage?
Yes, that is the definition of a shortage. When demand/supply is high enough that developers can demand salaries that many segments of the market cannot afford, then there is a shortage.
Where are the long lines of companies waiting at the developer stations?
Slashdot Mirror
Or it could just honor fstab since that has always been the correct way to specify mounting a filesystem.
Not really. If systemd is monitoring the mounts, which it does because executing mount -a at some arbitrary point during the boot process is not the best way to mount the required filesystems during boot, it makes sense for it to give priority to it's own config files. Anyway, I don't know the exact nature of the problem, but I suspect it is because systemd mounts filesystems before /etc/fstab is parsed. If you try to mount an already mounted filesystem, it will just get ignored. This is the default behavior of the mount command and has nothing to do with systemd.
I see no reason that should need to touch system logging at all other than adding a log entry if it has to take action.
Agreed. It doesn't need to, but the two activities are logically connected. Technically, journald is a separate service from systemd that is designed to work well with systemd, and it collects a lot more information than your basic syslogger. It is not required, though, and you can continue to use syslog if prefer it.
It's a massive, complicated, and very poorly behaved substitute for a simple, robust, and well behaved program. And it's not just a regular program, it is (if used as intended) a critical system component that will take your entire system down when it goes wrong.
Not at all. Don't substitute you not understanding a system with complicated and poorly behaved. There are careful design decisions and planning of systemd. You may not agree with them, but that doesn't make it wrong. Systemd is increasingly more popular for a number of very good reasons. It has become a freedesktop.org standard. You could start by reading this,
http://0pointer.de/blog/projec...
But since you probably won't, let me just say this. Serially executing a bunch of arbitrary shell scripts has got to be the worst possible way to design an init system. The fact that it works doesn't make it good. First of all, each script is code. Second, no script is aware of any other scripts presence, although intrinsically linked to and dependent on those other scripts. Third, a typical shell script is >100 lines of block logic to implement the equivalent of "service start". A configuration file for systemd for a single service can often be less than 10 lines and very easy to read.
I know I know, none of that matters, it is too "massive" and "complicated".
Maybe, but I don't know when "back when" was. A distribution has to make some choices about how to package things and that necessarily removes choice from the end user. Most basic example of this, the package manager. You can't really choose which one you want and which format. The distribution chooses the package manager, you choose the distribution. Or better yet, initmodutils, replacing insmod with modprobe. It's funny how users seem to fine with that, but when the distribution makes a decision they don't like, then it is being "shoved down your throat."
I'm not sure if you are arguing it is better for the computer or better for the human reading it. I dunno, I prefer human-readable plain text files over an easily parsable "complex syntax", especially for something as basic as the init system. That's why I (mostly) hate xml as a configuration file format (*cough* launchd *cough cough*). It is good for making guis, but terrible if you ever need to edit the file by hand at a terminal.
When it takes over file system mounting, including hiding most mount points
I can see how this is annoying, especially when you don't know what is going on, but mounting filesystems is an integral part of the startup process and therefore should be managed (in part) by systemd. It was manged using the old sysV scripts too btw, so it is consistent as far as init systems go. The difference with systemd is it actually knows what a filesystem is and that it is different from a service, so it can manage and monitor them accordingly. What this means is that filesystems associated with booting (root, swap, dev, ...) are now systemd entries instead of /etc/fstab entries. Once you realize this, it is not that hard to manage. And /etc/fstab does still work, of course, for filesystems you want to manage yourself. There are reasons you might want to create systemd entries for those too, though. Automounting, for example, is handled much better with systemd than the old autofs route that we had to use before.
and breaking silently if there are perfectly valid mounts in there which it happens not to like
That is either a bug, or possibly a conflict. Again, I can see how it is annoying, but if you have an /etc/fstab entry that wants to steamroll a systemd entry, it is understandable that systemd will try to stop that from happening. The correct fix in that case would be to edit the systemd entry to match the changes you are trying to make with the /etc/fstab entry.
When it takes over system logging
So, systemd doesn't just start/stop services, it also monitors them and can be configured to take certain actions depending on what happens to a particular process. So, needless to say, logging is kind of inherent to the whole thing. Correct me if I'm wrong, but I don't think it "taking over logging" is your real objection, but rather the way in which it does its logging. Instead of splitting things into separate text files that are managed by their respective daemons, systemd collects all this information and stores it in a standardized, indexed way within its own file. This is a design decision, and with all design decisions there are tradeoffs. In this case you are sacrificing the ability to just cat/grep individual text files for the ability to filter and have other processes able to monitor the log files, as well as some benefits for auditing and security. I definitely prefer text files because I don't manage complex scenarios, but I can also see how journald is critical for certain enterprise infrastructure. If you don't like journald, you can install syslog-ng. You just have to make sure it doesn't trample on journald (ie: it has to listen on the journald socket instead of /dev/log). I believe CentOS 6 is configured this way (journald+syslog-ng), so it is not that unusual or hard to do.
Never used SMF, but systemd is quite a bit better than launchd. The configuration files are all plain text. The major difference from a configuration point of view is that instead of writing a script, you just specify executable information, dependencies, sockets, etc, in a config file. That's it. Doesn't seem like such a big deal to me and in many ways seems quite a bit better than sysV.
Hate to break it to you, but when you install a distribution, you have a lot of software "shoved down your throat." It is what a distribution is, after all, and has been the case since forever. The maintainers decide what functionality is in the base system, what packages are installed in meta packages, what versions, what optional features to compile in. The only way around it is to use a source distribution like gentoo.
First, I have to ask, what is wrong with systemd? It actually works quite well.
That said, even with systemd (and upstart), sysV scripts are supported for backwards compatibility because quite a few system services do not yet have a systemd startup script. I have not looked at the networkmanager or policykit packages, but I am almost certain the dependency is only because of the startup script. If you grab a sysV script, you won't need systemd to install them. This will likely require some voodoo with the package manager, though. My recommendations in order of ease,
1) use --force to ignore the dependency (this might great problems if you ever have to repair the dpkg database, though)
2) grab another package from some other distro and install (with alien if need be)
3) tweak the package yourself to remove the dependency (wouldn't be hard to maintain wrt updates, etc)
4) compile from source and install (create your own package for maintainability)
Why do the media companies keep making this tired claim? 1 bazillion downloads doesn't equal 1 bazillion lost sales because not everybody would have bought the special edition dvd with holographic cover art. Wait, what were we talking about again?
And why would efficient use of screen real estate be applicable only to netbooks? I would like the majority of my screen to be used by what I am currently working on, not a bunch of user interface clutter.
Also, note this statement in your own Wikipedia reference,
"Canonical announced it had engineered Unity for desktop computers as well and would make Unity the default shell for Ubuntu in version 11.04."
Uh, ok, like another reply says, how often do you need to look at every application on your system?
Here are a few scenarios that come to mind.
1) Need to run a specific application.
a) Click the Dash, type a few letters, click the application or,
b) Click the Dash, click the categories view, filter by category, click the application or,
c) Find your application, drag it to the Launcher for quick access
2) Need to see all "Internet" applications.
a) Click the Dash, click the categories view, filter by category
3) Need to launch an application, but don't remember it's name, only something vague about it.
a) Click the Dash, type a few letters (not necessarily the beginning of the name), go aha!, click the application
4) Need to find a document that you were working on, but don't quite remember the name or where you put it.
a) Click the Dash, type a few letters (not necessarily the beginning of the name), go aha!, click the document
On the classic interface, 1b and 2a are possible. The rest are not. So while Unity may require a couple more keypresses in some comparisons, it seems more capable and flexible to me as a desktop.
Now ads are annoying, yes. I don't like that. Thankfully you can disable it. I also don't like the global menu, which this article is about. They seem to be changing it.
why do you think Unity was not designed for desktop computers? been using it on one for almost 2 yrs...
They are throwing out "network transparency"
Except that they aren't. Because X has not had true network transparency for over a decade. It does the same screen-scraping that RDP does, but just in a horribly inefficient way. X doesn't even have proper security, which is why remote sessions are tunneled through SSH. If you think that is efficient, you are probably the type of person that runs an IPSEC tunnel through the Tor network for fun just so you can check your email. The only advantage X has going for it is convenience. Remoting just works with no extra configuration required, just an X server (on the client, yay confusing X terminology). There are much better ways to do remoting. We can do better for linux, and Wayland provides the opportunity to engineer something good, without needing to hold on to legacy baggage.
This was my first reaction too. However, reading the article (I know, I must be new here) clears it up,
There are two reasons birds might fly in a V formation: It may make flight easier, or they’re simply following the leader. Squadrons of planes can save fuel by flying in a V formation, and many scientists suspect that migrating birds do the same. Models that treated flapping birds like fixed-wing airplanes estimate that they save energy by drafting off each other, but currents created by airplanes are far more stable than the oscillating eddies coming off of a bird. “Air gets pretty darn wiggy behind a flapping wing,” says James Usherwood, a locomotor biomechanist at the Royal Veterinary College at the University of London in Hatfield, where the research took place.
Just as aerodynamic estimates would predict, the birds positioned themselves to fly just behind and to the side of the bird in front, timing their wing beats to catch the uplifting eddies. When a bird flew directly behind another, the timing of the flapping reversed so that it could minimize the effects of the downdraft coming off the back of the bird’s body.
“From a behavioral perspective it’s really a breakthrough,” says David Lentink, a mechanical engineer at Stanford University in Palo Alto, California, who was not involved in the work. “Showing that birds care about syncing their wing beats is definitely an important insight that we didn’t have before.”
And from the actual research article,
Many species travel in highly organized groups. The most quoted function of these configurations is to reduce energy expenditure and enhance locomotor performance of individuals in the assemblage. The distinctive V formation of bird flocks has long intrigued researchers and continues to attract both scientific and popular attention. The well-held belief is that such aggregations give an energetic benefit for those birds that are flying behind and to one side of another bird through using the regions of upwash generated by the wings of the preceding bird, although a definitive account of the aerodynamic implications of these formations has remained elusive.
We conclude that the intricate mechanisms involved in V formation flight indicate awareness of the spatial wake structures of nearby flock-mates, and remarkable ability either to sense or predict it. We suggest that birds in V formation have phasing strategies to cope with the dynamic wakes produced by flapping wings.
So, it's a little bit of a behavioral science study...is saving energy why they do it, or is saving energy just a happy consequence? And it's also a bit of a mechanism study...to gain the most aerodynamic benefit requires adjustment of the wing and position to meet the updrafts, so how well do the birds do this?
Uhhhh....
http://www.ubuntuupdates.org/package/xorg-edgers/precise/main/base/xserver-xorg-video-intel
If you're telling me it doesn't work (don't have one to verify myself), fine, sounds like it needs a bug report. KMS has nothing to do with anything. Using an older AMD driver doesn't preclude you from using a new and updated distribution. Ubuntu has had "nvidia-legacy" packages for similar reasons for years. Not sure why you don't like the radeon driver, but https://launchpad.net/~makson96/+archive/fglrx. It says 13.10 and beyond will be more of a pain, but 12.04 is supported now and will be until 2017.
What do you mean by supported, and why do you think your laptops weren't?
I think what he means is that the network transparency feature of X11 involved sending X primitive commands over the network to be rendered on the remote X server. With the modern desktop environments and toolkits this doesn't happen. Yes, you have a remote display, but it is sending pixmaps and screen buffers over the network instead of X primitives. So it is slow as hell and doesn't take full advantage of the local (client) hardware.
That's almost, but not entirely, true. ALSA had kernel-level software mixing (dmix) that any application written to use ALSA could benefit from. As long as I used 100% ALSA applications, it worked fine. The problem was, as you say, not all applications would support ALSA. They would use OSS and rely on the bridge device between /dev/dsp and the /dev/alsa devices as a compatibility layer. The mixing would still work if you were using 1 OSS application and 10 ALSA applications, but not if you were using 2 OSS applications. The solution was a higher level sound-mixing daemon that could abstract the hardware layer away from the applications. Again, the problems as you state were incompatible daemons between KDE and GNOME, until finally PulseAudio comes along which does two things. It abstracts the hardware much further (ex: it supports network sounds devices), and it hooks into everything (OSS, ALSA, ESD, artsD, Phonon), so any application written to use any sound subsystem will go through PulseAudio first. I'm not sure PulseAudio is the best solution, it has issues with latency and so forth. But getting all disparate software projects to agree on a single sound subsystem is harder, so it was never done. I believe there were a few attempts to get either ESD or artsD into a Freedesktop spec, but that never went anywhere.
a) This isn't radio. Spotify's user base isn't that large, so 2% isn't as much as it sounds.
b) The more songs you have, the better chance you have of somebody listening to it. So if you have only one song, yeah that might be hard to hit. But if you have 40, it is easier.
c) Big caveat to my calculation: I don't know what Spotify's sliding scale is. For 2% of the user base, the payout may be significantly larger and thus the required number of plays to make a reasonable income smaller.
d) Spotify's revenue comes from ads, so it makes sense to split it up based on how popular a song/group is. If only 0.01% of the user base is listening to your music, you can't expect Spotify to give you a large piece of the ad revenue generated by their service.
The entertainment industry, whether it be music, tv/movies, or sports, is about popularity. If you can't boost your popularity, it just isn't going to work out, regardless of Spotify's business model. That is the reality.
400,000 plays?
Ok, let's stop and think about that for a moment. If you are a serious enough musician that you intend to do this professionally, let's assume you have put up at least 1 album, which for the sake of argument is about 10 songs. Spotify has 24 million active users, http://press.spotify.com/us/information/. So to make the 400,000 play cut, about 2% of Spotify's user base has to listen to at least one of your ten songs per month. That does not seem unreasonable to me. If you can't make that cut, the professional music gig probably isn't going to work out for you, sorry.
Am I missing something here?
Um, no, not really.
You are right, they should do more work on the study and get more data. But any questions about statistical significance and/or experimental design should have been addressed at the peer review stage. And then after that, there is even a final decision by the editor-in-chief to actually publish the study. Bad science or no, the study made it through. It happens all the time. See the arsenic in DNA controversy, or the huge argument over a generalized mechanism for antibiotic killing by reactive oxygen species. I can pick up papers from the 80s where they didn't purify their enzyme well enough and determined the wrong kinetic mechanism. What was the response to all of these? Different groups performed different studies and refuted the original findings. Sure there was a lot of clamor as well, but ultimately it was the experiment that settled the issue.
Calling for retraction in the absence of any kind of experimental evidence is not the way to handle this. I am not surprised the authors refused. Retraction has a huge stigma associated with it, and if they weren't deliberately fraudulent, they don't deserve it. The scientific community can scorn all they want, but it means nothing without experimental evidence to back it up.
Can we say arsenic in DNA?
http://www.sciencemag.org/content/332/6034/1163
It was only a few years ago, but I guess it has already left the public memory. A group of scientists rush to a hasty conclusion because they want to make a big splash. Science publishes it because they like controversy. A large flurry of criticism from the scientific community, but ultimately a number of papers get published refuting the original findings. We can ask the question...should it have been published? A lot of people think no, but it is an illustration of the scientific process.
Sometimes bad science gets through peer review. Sometimes the science is not particularly bad, but the experimental design was missing something. Maybe they had an impurity in one of their reagents that they weren't looking for. Lots of incomplete or just outright wrong studies pass peer review and get published. But this is something the scientific community accepts as a part of the process. If you strongly disagree or suspect the conclusions of an article, do the experiments and publish a counter-study. Otherwise, you are free to make a lot of noise and be annoying, but then you might go the way of James Watson.
but I just went to a training course to learn about a high-end enterprise product that runs on top of Linux
Uh huh, sure. Unless your "high-end enterprise product" runs on a 10 yr old copy of Slackware, what you've written is complete baloney.
Compare this to a sample PowerShell pipeline "Get-Process -Name 'n*' | sort -Descending PagedMemorySize"
As I'm sure you had to learn how to use Powershell, you will likewise have to learn how to use the command line in linux. And when you do, you will know what -e does for the most important commands. Btw, the majority of common linux commands have long-name switches along with their shortened counterparts (ex: cp -a vs. cp --archive), as well as quick --help pages to refresh you if need be.
Rail is optimal for regional distances. The faster the train, the larger the regional area it can serve. Ex: 200 mph makes serving a 600 mile area practical. Much faster than a car. Competitive with a plane when you consider time through security, comfort, etc. I used to take the Amtrak back and forth from home when I was in college. Driving might have been a bit faster, but not cheaper. And the train was a lot more comfortable.
For cross-country trips, that is the domain of air travel. No need to try to solve every problem with the same tool. Get rid of all of the crappy regional jets that are loss leaders anyway and replace with a nice train system. Bonus points if you can seamlessly connect between a flight and a train trip.
Does simply not wanting to pay more for something mean there is a shortage?
Yes, that is the definition of a shortage. When demand/supply is high enough that developers can demand salaries that many segments of the market cannot afford, then there is a shortage.
Where are the long lines of companies waiting at the developer stations?
Everywhere. Maybe you have not been paying attention.
http://www.pcworld.com/article/223509/demand_for_workers_outstrips_supply_first_since_2008.html
http://www.careerbuilder.com/share/aboutus/pressreleasesdetail.aspx?id=pr645&sd=7/13/2011&ed=12/31/2011&siteid=cbpr&sc_cmp1=cb_pr645_
http://www.bankrate.com/finance/jobs-careers/biggest-worker-shortages.aspx#slide=4
https://www.nixonwilliams.com/blog/post/07/2013/Temporary-IT-worker-demand-rises-to-two-year-high