Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Slashdot Deals: Cyber Monday Sale! Courses ranging from coding to project management - all eLearning deals 25% off with coupon code "CYBERMONDAY25". ×

Comment Lets open asteroid mining to private investment (Score 1) 211

The concern over this is bizzare. The way these people talk as if you can only use an asteroid for scientific means is insane. These people are worried about mining some lifeless rock when we are turning areas of the earths surface into moonscapes for mining? If we have a way that we can alleviate the strain on limited terrestrial resources, and reduce the impacts of mining on terrestrial ecosystems on earth, I think we should go for it. The idea that private companies should not be allowed to invest and be able to recoup their investment and make a profit by making their product available on the open market to benefit consumers is nuts. Here we have a way to mine a lifeless body in space instead of mine some rainforest on earth, if someone can figure out how to do this, kudos, if its a private company, thats great, everyone will benefit. Private investment helps fund these kinds of things without need for as much taxpayer confiscation.

Comment General concept of systemd not bad (Score 1) 572

Dependancy and target based startup is not a bad idea and can be useful in many scenarios. Its probably not necessary to start many services, though many admins can benefit from the feature where needed and it can actually make administration easier. Since SystemD provides Sys V init, and backwards compatability, the criticism of systemd is a bit overblown as people can simply use system v init features on systemd if they want. The integration of cron, syslog and init was important for being able to launch a service dependant based on say another cron event occuring. There are better ways to do this however using a decentralized model using well defined IPC bus interfaces and protocols allowing for the functionalities to be in seperate processes but allowing processes to communicate with each other, and each a user swappable components as I will describe later. There is no need to have one big monolithic process or poorly understood components which are not swappable and do not communicate using well understood and documented protocols that can facilitate users swapping out components.

I doubt that systemd would be as big of a controversy as it is if the additional functionality was added but not heavily used all over the place for most of the services on the system and the distribution had not felt the need to convert every single service to the new type of init file. Its sort of like people who think they have to use every single C++ feature when C++ is not intended for that, its a bag of tools where the programmer is supposed to choose the tool they need, rather than something where the programmer is supposed to use every single last tool. Instead, the distributions who adopted it felt the need to convert most services over to the new init file format. This created a very much so in your face kind of obtrusiveness that was easily noticeable by many. It was unnecessary in many cases as dependancy based startups can stil even be triggered from System V style initializations. Since systemd supports SysV startup, the majority of init files could have been left in SysV format which would have avoided much controversy. Another possibility is to offer init files in both the old and new formats so people can choose which one they desire.

I believe in a mechanism not policy approach. Systemd's own model of dependancy init are useful in some cases however, are probably overkill for other services. The features should be there for those cases that people may need to use them. Systemd does allow users to the flexibility to use sysV init so the fact is for starting your services you can always have the started from sysV scripts even on Systemd. Ive done it and works fine.

Many complain about the all or nothing approach of systemd. An init system like this should be built around IPC bus, using well defined protocols, interfaces and message formats which are extremely well documented to the public. This way we can get the dependancy based start up, while giving admins complete control and allowing the init system to be built from swappable components. Lets say we wanted to have a daemon started after 5 conditions are fulfilled, 3 other daemons started, the network interface up and 5 minutes elapsed from system boot. The init components that start the 3 prereq daemons would produce IPC bus messages as each of those are started. The kernel would generate a bus message when the network interface would go up. You could write your own init daemon that would watch the bus for all of these events and would also set a 5 minute timer as well, it would keep track of all of these events and when all of them are fulfilled it could then start the daemon and would announce on the bus that it it doing so.

This would allow you to write drop in replacements yourself for any part of the init system. The bus interfaces would all be well documented so you could write your own python script if you wanted to watch the bus for events and be able to start a daemon or process when you see the prerequisite events on the bus. This would allow you to do as much custom logic as yuou need, as you can directly watch the events and messages and write whatever logic you need to of whatever complexity you need to react to the event and messages.

In this bus based design, sysV compatability layers would simply be a client on the bus and would each sysV service is started.

If someone decides to use another init system altogether, the sysV init scripts will still work okay but you would lose the additional functionality that you cannot get from system V scripts alone anyway.

Another gripe that has been heard a lot is the monolithic cron, init and syslog. Under the bus based design, these are completely seperate components that would communicate over the well defined bus interface, so each one of these programs can be easily replaced with whatever the user wants to use. This is a loosely coupled design. Even under systemd, it should be entirely possible for someone to run their own cron daemon if they want to. Under the bus based design, the cron would not have to be bus aware but, its an added benefit should you want to start another service on a cron generated event. As far as the syslog daemon, in the bus design the system consists of two parts, the syslogd reciever daemon that would take syslog messages via syslog protocol from applications, and put the messages on the bus, and any number of other syslog logging daemons that would watch for these messages and would write them to a log file or do something else with them. All of this is user swappable. since applications interact with this daemon, one solution for people who want their own syslog might be to set an environment variable to tell your own servers what syslog daemon to use, which would avoid making any systemd dependants unhappy. In the bus based design, the syslog could easily be swapped out as desired.
  It is always important to provide backward compatability, and everything here would support all existing interfaces, standards and conventions including cron, sysV init, syslog protocols and files, etc. The bus design provides all of these components in a completely replaceable and user swappable fashion. With the situation with pulseaudio, for instance, applications should have used a library that supported a fall back to open sound and ALSA type APIs if PulseAudio was not available, in addition to allowing open sound API apps to easily work on PulseAudio systems, and it would be important to provide libraries right off the bat that do this, to assure that things work seemlessly.

Comment Re:The Commit Message (Score 1) 572

Any init system like this should be built around an IPC type design, using something like DBUS,involving well defined protocols. This would allow you to drop in replacements of your choice for different parts of the system. Each component would listen to well defined messages that it is interested in. For instance, if you have a daemon that wants to launch after another daemon, when the first daemon is launched by init, a message is issued announcing this on the bus, and other modules can listen for this and react to it how they see fit. The init system should be based on a set of standards, with facilities for non-standard or pre-standard extensions that can be developed since we cannot anticipate before hand every need that someone may have. But with well defined interfaces the components can be swappable and things will still be able to work together.

What problem someone would have with this, I have no clue.

Comment Re:WTF? (Score 2) 220

One of the complaints of software vendors has been that with Linux you would have to maintain a completely different installation package for each of the 200 Linux distributions. LSB was meant to help fix this problem. Abandoning the effort bodes poorly if people who want to ship binaries, this does not include just proprietary software, many, many open source projects also distributes binaries, so if your going to abandon LSB your really setting back and really wiping out a facility for distribution nuetral packages.

Secondly, LSB was not a mandatory install as I recall, you could choose not to install many LSB packages so not as if you did not have any use for it your resources are going to be used for it;.

Just a lousy decision, another politically driven decision by debian which seems show indifference to the need for cooperation between distributions for interoperability.

Comment Re:First systemd, now LSB (Score 2) 220

Systemd is not bad at all really, all of my scripts execute well. Maybe the default settings are not what you need so you just configure some of your own rc style scripts to be run and problem solved. Its not like systemd hs taken away the old startup model, you can use it quite happily under systemd, so I don't know what the problem is. No one is forcing you to use prerequisite based startup in systemd and I do not myself, all systemd is adds additional capability to what is already available.

Comment Why would ET use gravity or neutrinos (Score 1) 275

I was of the understanding that current radiotelescopes could not pick up a regular broadcast signal of the type that is sent by commercial transmitters but that the signal would have to be much more powerful and concentrated, intentionally sent for the purpose of detection from another planet. I suppose that I was wrong?

Secondly, what benefits would a gravity or nuetrino have over EMF for communications? If it was so great why wouldnt be we be using it? How would you create a gravity or neutrino communications device? An expensive, complex communication technique just because it would be hard to use doesnt make it more practical and ETs are likely to be practical.

Comment Re:The elephant in the room (Score 1) 176

Another way it can be changed is actually enforce sodomy/cohabitation laws (ban out of wedlock sex) and make divorces almost impossible to get. All of these laws were once in place but were dismantled by Liberals. So stop telling us nothing can be done about the problem, the only reason nothing would be done about the problem is you Liberals would stand in the way of doing these things, you are the ones that pushed for all of this madness of divorce on demand, the breakdown of marriage, the legitimization of having chidlren outside of wedlock, etc, and these policies lead to the dismal situation in the Black community. You Liberals want to make sure that people can have free sex, one night stands, produce illegimate welfare children, pass around the STDs and live a totally reckless, gluttonous and self centered lifestyle becuase it produce more of the low caliber, deranged, psychotic, and America hating voting block that your DemocRATic party depends upon.

Comment Re:The elephant in the room (Score 1) 176

It could be changed, by reforming the welfare programs to stop making having welfare babies out of wedlock pay. There are a lot of possibilities for doing this, such as not giving out welfare benefits on a per child basis, not giving out services to the parent but directly to minors (a soup kitchen type setup). Also get rid of the Earned Income Tax Credit. The problem with the way that many of these programs work is they give more money to the parent or every illegitimate child, the parents can then use this money how they want, on themselves.

Comment Firefox still woefully insecure (Score 2) 113

Firefox is still far more insecure than Chrome due to lack of a sandbox feature and multiprocess. Instead of spending so much time on pocket they needed to get the sandbox done. They should have had the sandbox in 3 years and are only dragging their feet on it being forced to keep up with Chrome on this matter.Still a very insecure browser. Total negligence. Whats ironic is they would mainly need to plugin into infrastructure that was already implemented for Chrome on Linux, as it was Chrome that pushed implementation of a process sandbox on Linux.

Ocean: A body of water occupying about two-thirds of a world made for man -- who has no gills. -- Ambrose Bierce