*bullshit* It is that easy. Because some sane and nice people who care about not using systemd as pid1 have actually put in the work to do so.
systemd is only taking in everything as much as nobody is willing/able to provide comparable functionality. Eg, there's no credible replacement for systemd-logind. ConsoleKit is unmaintained and less powerful. Developers of desktop environments and distributions want to take advantage of it's functionality and avoid the trouble of trying to get shit done using ConsoleKit.
But enterprising souls (ok, mainly from Ubuntu) have come up with enough functionality (cgmanager) to run systemd-logind without having to run systemd.
Then for f**ks sake, apt-get install something_else and stop bitching.
XFCE, LXDE, KDE, MATE, etc, etc, etc, are only a few apt-get commands away.Likewise, systemd (pid1) can be replaced by sysvinit (and systemd-shim if needed) with a few commands and one reboot. NOBODY is putting roadblocks in the way of the Debian developers who are willing to put in the work to keep Debian as functional as possible without using systemd as init.
The entire Debian issue is a storm in a teacup, fueled by zealots to whom the mere presence of libsystemd in their hard drive is unacceptable and "freedom of choice" seems to mean that nobody should have the choice of using systemd.
Most servers run on Windows or Linux, mainly in the form of RHEL and SLES. Anything else tends to mean the hardware and software providers don't support you, which can be quite inconvenient. Outside hobby servers, the number of servers using BSD or unsupported Linux distros (eg, I run Debian on personal systems) are a minority.
When dealing with systems with more custom hardware designs, things get varied. Cray XT6's compute nodes run a lightweight Linux installation, while IBM's BlueGene compute nodes run a custom OS with is only a few thousand lines of code. But supercomputers we'd call clusters usually run RHEL or SLES or derivative with some add-ons. Comparing with BSDs is non-sense.
Among embedded systems with a multi-tasking memory protected OS, the most common sightings are QNX, VxWorks and Linux [full GNU/Linux, Android, WebOS, etc]. I can't recall the last time I saw a shipping product with NetBSD, actually. Despite it's fame for portability, NetBSD has been trailing Linux for a while and it lacks support for a number of modern embedded platforms. From the top of my head, there's no NetBSD support for AVR32, NIOS or Blaze architectures.. I don't think there's working support for FPGAs with embedded ARM CPUs either.
To me, it looks like you're taking your hobby approach to work.
If you're using professional (lack of better word) proprietary applications from Xilinx, Cadence, Mentor, Oracle, Autodesk etc, in Linux you should do it on a supported operative system version: RHEL or SLES. Of course, if you're running in Windows is fundamentally the same situation. Usually, application developers target and support only a few version version of Windows. Eg, check https://www.cadence.com/rl/Resources/release_info/Supported_Platforms_Matrix.pdf
If you do that, it works relatively well -- no better, no worse than Windows. If you go with anything else you're a) asking for trouble and b) their support won't even help you. Even if you run CentOS, which is 99.99% compatible with RHEL, expect their support to refuse assistance until you migrate to RHEL.
Other than that, as your experience with Cadence shows, there is actually a large body of niche applications which is not available for Windows or where Windows is a second class citizen for the developers. Another example from the top of my head is ROOT, the main data analysis framework used at CERN.It's mainly developed for Linux, including the graphical user interface parts which make the plots. OS X and Windows are second and third class citizens.
And their number seems to be increasing. For example, in the last few years Xilinx brought the Linux version of their tools to parity level with Windows (they're equally crappy now). And Altera brought their Linux tools from basic-and-expensive to almost parity with their Windows tools (there's a few glitches in the GUI).
The other poster was wrong: dmix runs in user space. Linux never had kernel space mixing/resampling, unless you patch it with OSSv4. Which means your post is bullshit.
dmix doesn't run in kernel space, it runs in user space. In an ugly way, by the way: the first application to load the dmix plugin forks() a process which run as the sound server.
That said, dmix was a very simple sound server that mostly did the job but PulseAudio does it better and also implements a long list of wanted features.
Despite FlyingGuy's somewhat US-sub fanboish tone (sorry!!), his fundamental proposition is correct. Exercise after naval exercise has confirmed only one thing: even not-so-modern submarines are a nightmare for even the most modern surface fleets, as all the detection technologies have severe limitations. Active sonar has limited range; passive sonar depends on the target's noise. Both are seriously affected by the noise environment and the ocean's thermal layers Magnetic anomaly detection has very limited range and can be defeated/partially defeated by minimizing the use of ferromagnetic materials (such as Germany's U-212 class). And they can attack a target without exposing their position too much. Launching a torpedo does no longer require you to yell the world "Here I am and this is my street number". Modern torpedoes can quietly be launched and guided through an arbitrary path before before closing in on the target and being detected. By the time a target detects a incoming torpedo, the launching sub can be somewhere in a few hundred of km of ocean, which already is a lot to canvas.
And the innovations mentioned in the article smell a lot like bullshit by the way. LED light of the submarine hull???
I've been using Debian unstable in my personal computers for years. Occasionally, something breaks.
But I prefer the long term support of Debian stable and CentOS for internet facing servers and lab workstations. Here, it's important to be able to get security fixes without fear of breaking anything for years.
1. Cut out those which don't have best $/transistor process nodes (~32 nm -- ~14 nm depending on who you ask). 2. Cut out the memory fabs, their processes aren't suitable for general purpose logic. 3. Dig in and notice cases like CNSE which is actually GF. The remaining list is those 3 plus Intel.
Optimization per fab is a bloody understatement. To have something that is even close to competitive in performance/power/area you need to a) custom design your gate array to each process b) characterize the resulting chip from each process so the EDA tools can produce something close to a good solution.
I fully appreciate you need the FP part in FPGA. What I was trying to say is that those users who don't need the FP part are already helping drive the FPGA prices down for high volume applications.
I don't think there's an open source FPGA design can bring much margin for improvement in pricing. Keep in mind is that the FPGA manufacturers already have a type of competition: beyond a certain point, it's cheaper to roll out your own ASIC. This already constrains the volume and price on their low end offerings.
You're also being quite naive about competition between "cheap" manufacturers, when applied to semiconductors. First challenge is that lowest cost/transistor is provided by relatively modern processes (eg, 32-22 nm) and your fab options are few and the same as Xilinx/Altera's: TSMC, Samsung or GF. Second challenge is that it takes a considerable ammount of effort/time/money to move a design between different manufacturers (and the more optimized, the worse).
The other issue is that commercially available FPGAs have limited market lives. You could easily spend years developing an open source tool chain for a part that is available only on eBay as a "refurbished after removed from equipment".
It's not a totally of a different problem than faced by developers of open source compilers and graphic drivers: any given model is only in the market for a short while, much less than FPGAs. And while CPUs are usually* replaced by 100% backward compatible models, new GPUs aren't usually backward compatible. * Except when the entire instruction set architecture dies away.
The trick is, of course, to reuse as much of the code as possible to support different architectures.
Same thing is appliable to FPGAs and ASIC development. And people are actually doing it. A couple of interesting projects: http://code.google.com/p/vtr-verilog-to-routing/ http://www.clifford.at/yosys/ http://opencircuitdesign.com/qflow/
It's not yet Verilog to bitstream but some of the technically harder parts are getting done.
Err.. First, the Concorde cruised at Mach 2.0 without reheat. On the Concorde, reheat only added some 20% (IIRC) to the thrust was used mainly to accelerate to cruise speed.
Secondly, to design a more powerful/fuel efficient engine without reheat, you need to handle higher flows, temperatures and pressure. Reheat is a "cheap and easy" way to work around this issue, although at the expense of fuel efficiency.
That said, using more advanced materials which can handle higher temperature and pressures to build more powerful and efficient engines is the normal business in jet engines. Using modern materials and designs, one could surely design a high/medium bypass turbofan that is quite more efficient than Concorde's turbojets.
Listening to music is highly emotional and subjective. Claiming that vinyl, somehow, allows for a better one that CD is not subjective. Knowledge of human hearing, audio signals all point to one thing, confirmed by blind tests: if you take a vinyl and properly record into a CD-R, or FLAC, people can't tell the difference.
AFAIK, nobody has bothered to do a "proper" blind test of a vinyl vs something else. Some of us have done is casually: rip a vinyl to FLAC and it still sounds the same.
In my experience, people who are willing to understand the meaning of a double blind test don't need it to know CD is a better format than vinyl. As for the others, there isn't any amount of double blind testing which will reach them.
WARNING: a lot of vinyl editions of a given album DO sound better (to my ears) than the CD edition of the same album because they have a different masterization, The CD editions often have their dynamic range brick walled into oblivion, while the vinyl edition hasn't. Which is absolutely infuriating, as the CD has a larger dynamic range.
Some proper blind tests have been done of CD vs SACD/DVDA: "Audibility of a CD-Standard A/D/A Loop Inserted into High-Resolution Audio Playback". Summary: sound engineers, music students and the likes of which can't tell the difference between SACD/DVD-A and the same reduced to CD quality.
Legislation requires you to have insurance because, if you want to drive a car and incur in the risk of damages to third parties, society needs to ensure you (via your insurance) can bear (part of) the cost of reparations, instead of leaving it all on victims and the state.
Insurance is a free, competitive market. If it's not, your regulatory agencies are not doing their job.
Insurance companies adjust the fees based on what they perceive it's the risk you will cause/be involved in an accident but also on the amount of expense they can incur. If the Ferrari is driving people commercially, it spends more time on the road than your average private car and is thus more likely to cause/be involved in an accident than a Kia which is only used to commute from home to work. Also, if the Ferrari is damaged in an accident caused by the Kia, which happens to have the same insurance company, the insurance company will have to pay more than if two Kias had collided. It's the insurance's company prerogative to charge you more for spending more time on the road and bringing a more expensive car to the road. The insurance company may also have figured out Ferrari drivers are more likely to cause accidents.
You may not like this situation, but the Kia owner does. If you don't like, find another insurance company. Or buy a Kia and stop driving for Uber.
Despite the vague claims in their blog, there is no evidence that Uber is providing valid insurance for their _UberPOP_ drivers in _Europe_, nor that it is ensuring they have one. At least, the Frankfurt court found that they do not.
AFAIK, they do check that the UberBlack drivers have proper insurance.
Nobody was suggesting that the drone pilot was intentionally trying to hit the aircraft or that's it's easy to do so. But if you have a drone in the general vicinity of an aircraft, there's a chance it will end up being sucked into the engine, smashing through the cockpit or something else with dangerous consequences. And as you may or may not know, Murphy's law is a bitch.
Hundreds of aircraft get damaged each year by hitting birds. Some also get damaged by objects or animals in the runway. And that is despite airports taking huge (and expensive) measures to minimize the problem. These incidents cost a lot of money in repairs and, while most result in no harm, each represents added risk.
Having small RC aircraft flying around in the restricted airspace of an airport is an added risk for no good reason. People who operate these things should just be aware not to operate them near airports.
At this point, some people will somewhat rightfully complain. What does the init system have to do with this? Why can't we do this with sysv init? And the answer is "technically, no reason".
It just so happens that the only piece of software that currently can do this job properly (systemd-logind) is part of the systemd project and has a dependency on systemd(-init).
But at the same time, that dependency exists simply because no other project implements the necessary features. Once someone creates a capable alternative, the dependency will tend to disapear.
And this is already happening: there is still no credible alternative to systemd-logind, but there is a credible alternative to run systemd-logind without using systemd as init.
Yes, Wayland will "need" systemd Or more precisely, it needs something which does what systemd-logind does: manage the permissions of the hardware so that the compositor can use access them.
Quick history note: Until not so long ago, the vast majority of LInux systems ran the Xserver as root, because it was the only (practical) way to have it access all the hardware it needs to (graphics, mouse, keyboard). Only with systemd-logind it became practical to run the Xserver as $user.
Wayland needs the compositor, which runs as $user, to be able to access the hardware.
I use Linux on the desktop, for both personal and professional use. For me, a functional system requires me to run hundreds of packages. Several of them are large monolithic pieces of software for which I have no real alternative: the Linux kernel, the GNU libc, the X.org Xserver would be the best examples. Yes, there are alternatives but I can't run all I want/need to with them. systemd is a drop in the ocean.
Devuan is, quite honestly, the most irrelevant Debian derivative ever. And the reason is simple: regarding Debian, this is a storm in a teacup, created by people whose notion of freedom is to force others to follow their opinion. Debian has merely chosen to use systemd over SysV as default init. Debian has shipped alternative inits for ages and Debian has not put roadblocks in front of those who wish to put in effort to ensure Debian can be used without systemd as init. There are people putting in work to ensure you can run Gnome without systemd for almost as long as Gnome has depended on systemd. And they haven't been complaining. There is no need to fork Debian to accommodate them. As long as people are willing and able to do the work, you'll be able to replace systemd with something else with an "apt-get install sysvinit systemd-shim systemd-"
systemd is, first, a new init system for Linux, to replace sysv init. Additionally, it brings a host of companion daemons: logging (journald), a session manager (logind) and a bunch of others. systemd and it's companions offer a host of functionality and a number of software pieces are becoming to depend on it, to the point you "can't" run a fully functional Gnome3 without using systemd as init (it needs the session management functionally of logind, for example). The major distributions have adopted systemd as default init system: Fedora, RHEL, SuSE, Debian and Arch. Ubuntu hasn't changed yet but they have announced they will follow Debian in the future.
There is a number of people who dislike it for many reasons, which are hard to summarize because many of the people dislike it for false reasons and only some actually make valid and constructive critiques. Eg, many people claim it's monolithic. In fact, it's made of ~100 daemons and applications and the init process isn't that big. Much much smaller than the Linux kernel itself, which a big monolithic kernel.
Many peole dislike being "forced" to use because the major distributions are adopting it and major projects like Gnome are becoming dependent (with KDE talking about it too).
I use "" in "can't" and "forced" because it's not strictly true. While a lot of people whine and hate in slashdot, a small number of people have been putting their code where their mouth is and working on alternatives. Eg, there's a systemd-shim package in Debian which actually allows you to run Gnome3 very nicely without using systemd as init, by providing the necessary systemd features.
For the first link: - The survey was made only among geo-scientists and engineers in the province of Alberta, Canada (where the oil industry is a major employer), it's a world wide survey of experts in climate. - The actual results of the survey were "27.4% believe it is caused by primarily natural factors (natural variation, volcanoes, sunspots, lithosphere motions, etc.), 25.7% believe it is caused by primarily human factors (burning fossil fuels, changing land use, enhanced water evaporation due to irrigation), and 45.2% believe that climate change is caused by both human and natural factors".
Put simply, the article you linked in it outright lying.
Slashdot Mirror
*bullshit*
It is that easy. Because some sane and nice people who care about not using systemd as pid1 have actually put in the work to do so.
systemd is only taking in everything as much as nobody is willing/able to provide comparable functionality.
Eg, there's no credible replacement for systemd-logind. ConsoleKit is unmaintained and less powerful. Developers of desktop environments and distributions want to take advantage of it's functionality and avoid the trouble of trying to get shit done using ConsoleKit.
But enterprising souls (ok, mainly from Ubuntu) have come up with enough functionality (cgmanager) to run systemd-logind without having to run systemd.
Then for f**ks sake, apt-get install something_else and stop bitching.
XFCE, LXDE, KDE, MATE, etc, etc, etc, are only a few apt-get commands away.Likewise, systemd (pid1) can be replaced by sysvinit (and systemd-shim if needed) with a few commands and one reboot.
NOBODY is putting roadblocks in the way of the Debian developers who are willing to put in the work to keep Debian as functional as possible without using systemd as init.
The entire Debian issue is a storm in a teacup, fueled by zealots to whom the mere presence of libsystemd in their hard drive is unacceptable and "freedom of choice" seems to mean that nobody should have the choice of using systemd.
You need to get out more.
Most servers run on Windows or Linux, mainly in the form of RHEL and SLES. Anything else tends to mean the hardware and software providers don't support you, which can be quite inconvenient.
Outside hobby servers, the number of servers using BSD or unsupported Linux distros (eg, I run Debian on personal systems) are a minority.
When dealing with systems with more custom hardware designs, things get varied. Cray XT6's compute nodes run a lightweight Linux installation, while IBM's BlueGene compute nodes run a custom OS with is only a few thousand lines of code.
But supercomputers we'd call clusters usually run RHEL or SLES or derivative with some add-ons. Comparing with BSDs is non-sense.
Among embedded systems with a multi-tasking memory protected OS, the most common sightings are QNX, VxWorks and Linux [full GNU/Linux, Android, WebOS, etc].
I can't recall the last time I saw a shipping product with NetBSD, actually. Despite it's fame for portability, NetBSD has been trailing Linux for a while and it lacks support for a number of modern embedded platforms. From the top of my head, there's no NetBSD support for AVR32, NIOS or Blaze architectures..
I don't think there's working support for FPGAs with embedded ARM CPUs either.
Someone has to design the integrated circuits that allow you to post on /.
Be thankful we exist and suffer for you.
To me, it looks like you're taking your hobby approach to work.
If you're using professional (lack of better word) proprietary applications from Xilinx, Cadence, Mentor, Oracle, Autodesk etc, in Linux you should do it on a supported operative system version: RHEL or SLES.
Of course, if you're running in Windows is fundamentally the same situation. Usually, application developers target and support only a few version version of Windows.
Eg, check https://www.cadence.com/rl/Resources/release_info/Supported_Platforms_Matrix.pdf
If you do that, it works relatively well -- no better, no worse than Windows.
If you go with anything else you're a) asking for trouble and b) their support won't even help you.
Even if you run CentOS, which is 99.99% compatible with RHEL, expect their support to refuse assistance until you migrate to RHEL.
Other than that, as your experience with Cadence shows, there is actually a large body of niche applications which is not available for Windows or where Windows is a second class citizen for the developers.
Another example from the top of my head is ROOT, the main data analysis framework used at CERN.It's mainly developed for Linux, including the graphical user interface parts which make the plots. OS X and Windows are second and third class citizens.
And their number seems to be increasing. For example, in the last few years Xilinx brought the Linux version of their tools to parity level with Windows (they're equally crappy now). And Altera brought their Linux tools from basic-and-expensive to almost parity with their Windows tools (there's a few glitches in the GUI).
The other poster was wrong: dmix runs in user space. Linux never had kernel space mixing/resampling, unless you patch it with OSSv4.
Which means your post is bullshit.
dmix doesn't run in kernel space, it runs in user space.
In an ugly way, by the way: the first application to load the dmix plugin forks() a process which run as the sound server.
That said, dmix was a very simple sound server that mostly did the job but PulseAudio does it better and also implements a long list of wanted features.
A modern 155 mm howitzer has an accurancy of about 50-200 meters at a 20 km range with standard shells.
Unless you load them with GPS guided shells (yes, they exist) at which point is becomes a few meters at 60 km range.
Despite FlyingGuy's somewhat US-sub fanboish tone (sorry!!), his fundamental proposition is correct.
Exercise after naval exercise has confirmed only one thing: even not-so-modern submarines are a nightmare for even the most modern surface fleets, as all the detection technologies have severe limitations.
Active sonar has limited range; passive sonar depends on the target's noise. Both are seriously affected by the noise environment and the ocean's thermal layers
Magnetic anomaly detection has very limited range and can be defeated/partially defeated by minimizing the use of ferromagnetic materials (such as Germany's U-212 class).
And they can attack a target without exposing their position too much. Launching a torpedo does no longer require you to yell the world "Here I am and this is my street number".
Modern torpedoes can quietly be launched and guided through an arbitrary path before before closing in on the target and being detected.
By the time a target detects a incoming torpedo, the launching sub can be somewhere in a few hundred of km of ocean, which already is a lot to canvas.
And the innovations mentioned in the article smell a lot like bullshit by the way. LED light of the submarine hull???
I've been using Debian unstable in my personal computers for years. Occasionally, something breaks.
But I prefer the long term support of Debian stable and CentOS for internet facing servers and lab workstations.
Here, it's important to be able to get security fixes without fear of breaking anything for years.
I understand the motivation. I'm just not discussing the parts where I agree with you. :)
I just took issue with your original statement where you envisioned the open gate array dominating the low end market based on price.
1. Cut out those which don't have best $/transistor process nodes (~32 nm -- ~14 nm depending on who you ask).
2. Cut out the memory fabs, their processes aren't suitable for general purpose logic.
3. Dig in and notice cases like CNSE which is actually GF.
The remaining list is those 3 plus Intel.
Optimization per fab is a bloody understatement. To have something that is even close to competitive in performance/power/area you need to a) custom design your gate array to each process b) characterize the resulting chip from each process so the EDA tools can produce something close to a good solution.
I fully appreciate you need the FP part in FPGA. What I was trying to say is that those users who don't need the FP part are already helping drive the FPGA prices down for high volume applications.
I don't think there's an open source FPGA design can bring much margin for improvement in pricing.
Keep in mind is that the FPGA manufacturers already have a type of competition: beyond a certain point, it's cheaper to roll out your own ASIC.
This already constrains the volume and price on their low end offerings.
You're also being quite naive about competition between "cheap" manufacturers, when applied to semiconductors.
First challenge is that lowest cost/transistor is provided by relatively modern processes (eg, 32-22 nm) and your fab options are few and the same as Xilinx/Altera's: TSMC, Samsung or GF.
Second challenge is that it takes a considerable ammount of effort/time/money to move a design between different manufacturers (and the more optimized, the worse).
The other issue is that commercially available FPGAs have limited market lives. You could easily spend years developing an open source tool chain for a part that is available only on eBay as a "refurbished after removed from equipment".
It's not a totally of a different problem than faced by developers of open source compilers and graphic drivers: any given model is only in the market for a short while, much less than FPGAs.
And while CPUs are usually* replaced by 100% backward compatible models, new GPUs aren't usually backward compatible.
* Except when the entire instruction set architecture dies away.
The trick is, of course, to reuse as much of the code as possible to support different architectures.
Same thing is appliable to FPGAs and ASIC development. And people are actually doing it.
A couple of interesting projects:
http://code.google.com/p/vtr-verilog-to-routing/
http://www.clifford.at/yosys/
http://opencircuitdesign.com/qflow/
It's not yet Verilog to bitstream but some of the technically harder parts are getting done.
Err..
First, the Concorde cruised at Mach 2.0 without reheat. On the Concorde, reheat only added some 20% (IIRC) to the thrust was used mainly to accelerate to cruise speed.
Secondly, to design a more powerful/fuel efficient engine without reheat, you need to handle higher flows, temperatures and pressure.
Reheat is a "cheap and easy" way to work around this issue, although at the expense of fuel efficiency.
That said, using more advanced materials which can handle higher temperature and pressures to build more powerful and efficient engines is the normal business in jet engines.
Using modern materials and designs, one could surely design a high/medium bypass turbofan that is quite more efficient than Concorde's turbojets.
Listening to music is highly emotional and subjective.
Claiming that vinyl, somehow, allows for a better one that CD is not subjective.
Knowledge of human hearing, audio signals all point to one thing, confirmed by blind tests: if you take a vinyl and properly record into a CD-R, or FLAC, people can't tell the difference.
AFAIK, nobody has bothered to do a "proper" blind test of a vinyl vs something else.
Some of us have done is casually: rip a vinyl to FLAC and it still sounds the same.
In my experience, people who are willing to understand the meaning of a double blind test don't need it to know CD is a better format than vinyl.
As for the others, there isn't any amount of double blind testing which will reach them.
WARNING: a lot of vinyl editions of a given album DO sound better (to my ears) than the CD edition of the same album because they have a different masterization, The CD editions often have their dynamic range brick walled into oblivion, while the vinyl edition hasn't. Which is absolutely infuriating, as the CD has a larger dynamic range.
Some proper blind tests have been done of CD vs SACD/DVDA: "Audibility of a CD-Standard A/D/A Loop Inserted into High-Resolution Audio Playback".
Summary: sound engineers, music students and the likes of which can't tell the difference between SACD/DVD-A and the same reduced to CD quality.
Legislation requires you to have insurance because, if you want to drive a car and incur in the risk of damages to third parties, society needs to ensure you (via your insurance) can bear (part of) the cost of reparations, instead of leaving it all on victims and the state.
Insurance is a free, competitive market.
If it's not, your regulatory agencies are not doing their job.
Insurance companies adjust the fees based on what they perceive it's the risk you will cause/be involved in an accident but also on the amount of expense they can incur.
If the Ferrari is driving people commercially, it spends more time on the road than your average private car and is thus more likely to cause/be involved in an accident than a Kia which is only used to commute from home to work.
Also, if the Ferrari is damaged in an accident caused by the Kia, which happens to have the same insurance company, the insurance company will have to pay more than if two Kias had collided.
It's the insurance's company prerogative to charge you more for spending more time on the road and bringing a more expensive car to the road.
The insurance company may also have figured out Ferrari drivers are more likely to cause accidents.
You may not like this situation, but the Kia owner does. If you don't like, find another insurance company. Or buy a Kia and stop driving for Uber.
Despite the vague claims in their blog, there is no evidence that Uber is providing valid insurance for their _UberPOP_ drivers in _Europe_, nor that it is ensuring they have one.
At least, the Frankfurt court found that they do not.
AFAIK, they do check that the UberBlack drivers have proper insurance.
Nobody was suggesting that the drone pilot was intentionally trying to hit the aircraft or that's it's easy to do so.
But if you have a drone in the general vicinity of an aircraft, there's a chance it will end up being sucked into the engine, smashing through the cockpit or something else with dangerous consequences.
And as you may or may not know, Murphy's law is a bitch.
Hundreds of aircraft get damaged each year by hitting birds. Some also get damaged by objects or animals in the runway.
And that is despite airports taking huge (and expensive) measures to minimize the problem.
These incidents cost a lot of money in repairs and, while most result in no harm, each represents added risk.
Having small RC aircraft flying around in the restricted airspace of an airport is an added risk for no good reason. People who operate these things should just be aware not to operate them near airports.
At this point, some people will somewhat rightfully complain.
What does the init system have to do with this? Why can't we do this with sysv init? And the answer is "technically, no reason".
It just so happens that the only piece of software that currently can do this job properly (systemd-logind) is part of the systemd project and has a dependency on systemd(-init).
But at the same time, that dependency exists simply because no other project implements the necessary features. Once someone creates a capable alternative, the dependency will tend to disapear.
And this is already happening: there is still no credible alternative to systemd-logind, but there is a credible alternative to run systemd-logind without using systemd as init.
Yes, Wayland will "need" systemd
Or more precisely, it needs something which does what systemd-logind does: manage the permissions of the hardware so that the compositor can use access them.
Quick history note:
Until not so long ago, the vast majority of LInux systems ran the Xserver as root, because it was the only (practical) way to have it access all the hardware it needs to (graphics, mouse, keyboard).
Only with systemd-logind it became practical to run the Xserver as $user.
Wayland needs the compositor, which runs as $user, to be able to access the hardware.
I use Linux on the desktop, for both personal and professional use.
For me, a functional system requires me to run hundreds of packages.
Several of them are large monolithic pieces of software for which I have no real alternative: the Linux kernel, the GNU libc, the X.org Xserver would be the best examples.
Yes, there are alternatives but I can't run all I want/need to with them.
systemd is a drop in the ocean.
Devuan is, quite honestly, the most irrelevant Debian derivative ever.
And the reason is simple: regarding Debian, this is a storm in a teacup, created by people whose notion of freedom is to force others to follow their opinion.
Debian has merely chosen to use systemd over SysV as default init. Debian has shipped alternative inits for ages and Debian has not put roadblocks in front of those who wish to put in effort to ensure Debian can be used without systemd as init.
There are people putting in work to ensure you can run Gnome without systemd for almost as long as Gnome has depended on systemd. And they haven't been complaining. There is no need to fork Debian to accommodate them.
As long as people are willing and able to do the work, you'll be able to replace systemd with something else with an "apt-get install sysvinit systemd-shim systemd-"
systemd is, first, a new init system for Linux, to replace sysv init.
Additionally, it brings a host of companion daemons: logging (journald), a session manager (logind) and a bunch of others.
systemd and it's companions offer a host of functionality and a number of software pieces are becoming to depend on it, to the point you "can't" run a fully functional Gnome3 without using systemd as init (it needs the session management functionally of logind, for example).
The major distributions have adopted systemd as default init system: Fedora, RHEL, SuSE, Debian and Arch. Ubuntu hasn't changed yet but they have announced they will follow Debian in the future.
There is a number of people who dislike it for many reasons, which are hard to summarize because many of the people dislike it for false reasons and only some actually make valid and constructive critiques.
Eg, many people claim it's monolithic. In fact, it's made of ~100 daemons and applications and the init process isn't that big. Much much smaller than the Linux kernel itself, which a big monolithic kernel.
Many peole dislike being "forced" to use because the major distributions are adopting it and major projects like Gnome are becoming dependent (with KDE talking about it too).
I use "" in "can't" and "forced" because it's not strictly true. While a lot of people whine and hate in slashdot, a small number of people have been putting their code where their mouth is and working on alternatives.
Eg, there's a systemd-shim package in Debian which actually allows you to run Gnome3 very nicely without using systemd as init, by providing the necessary systemd features.
You should dig a little deeper.
For the first link:
- The survey was made only among geo-scientists and engineers in the province of Alberta, Canada (where the oil industry is a major employer), it's a world wide survey of experts in climate.
- The actual results of the survey were "27.4% believe it is caused by primarily natural factors (natural variation, volcanoes, sunspots, lithosphere motions, etc.), 25.7% believe it is caused by primarily human factors (burning fossil fuels, changing land use, enhanced water evaporation due to irrigation), and 45.2% believe that climate change is caused by both human and natural factors".
Put simply, the article you linked in it outright lying.