Debian dumping Linux Standard Base was really a big slam against interoperability.
Debian dumping Linux Standard Base was really a big slam against interoperability.
Maybe scan it with lasers and print out new dies on a 3D printer?
i think the whole point of it is to have a car that looks retro, just like the original, rather than to have a "modern" looking car. They are using a modern engine because the engine is "out of sight" and that a modern engine probably would work better. If you want a "modern" car you would just buy a modern car, if your buying a replica you dont want a modern car and wouldnt want it to look like one.
Also, tastes vary but I do not think that modern cars are all that pretty. I liked the sharp, crisp lines and edges of 80s styling. I think that looks more "modern" than the "snot glob" styling of modern cars.
Its nice to see this however we really should, in general, have a better way for Linux programs to be able to easily take advantage of the CPU extensions available without recompile. There are dozens of permutations of CPU extensions, so distributing a binary for each permutation is not feasible. Full from source compilation takes too long for many users. Having Linux binaries being able to use the CPUs most advanced features has been a problem. One solution that I favor is to take a page from AS/400, in a variation of that, in each library file, put a copy of the machine code, but also a copy of the abstract syntax tree, the last compilation phase. If the binary is moved to a new CPU, the AST is run through the code generator to regenerate the machine code in the file according to the options the CPU supports. All done in situ. This is much better than storing a copy a binary for each CPU permutation in a library file. It makes things easy to use and is faster than compiling from source as the lexer and parser phase does not need to be repeated.
Electric cars are supposedly an environmentally friendly technology. Has anyone looked at the *long term* sustainability and renewability of the battery technology and materials that are being used in the manufacture of the batteries. The toxicity profile is another issue, toxicity becomes much more of the problem when you are dealing with huge quantities and volumes of material as in a battery.
I know people talk about hydrogen. I once read a science fiction story about a planet that drained its oceans and killing itself off by burning up all of its water to make hydrogen, the free hydrogen would end up escaping the atmosphere into space. I dont know if thats a realistic scientific possibility but its something to keep in mind. What about creating all of that free hydrogen from water, what problems are there with the hydrogen then escaping the atmosphere? We need to consider the sustainability implication for the long term such as a billion years of use of such technology.
A technology which was of interest and which avoided many of these issues was cars powered by pressurized air. Tata in India was working on such a car. The benefits are that the storage medium of course is abundant, its a reuseable medium, its just air, its non-toxic, and its lightweight meaning that the car doesnt expend much energy to carry the fuel itself around. The air itself isnt harmed in any way, the air is stored and then released again, totally renewable. Fill-ups probably can be fast, as the pressurized air can be pumped from a tank at a service station into a car. There are some engineering difficulties but Tata was working on it. It could be a great thing if can be made to work.
Of course neither this and none of the aformentioned technologies are energy generation technology they are energy storage. With an air tank you might use say, a solar panel to provide the energy drive the air pump that pumps the air into the cars pressurized air tank. This stores the solar energy as pressurized air. The air is then gradually released from the tank by valves that drive the cars cylinders. To some degree the process can be inverted, you can create a vacuum and use the pressure of the surrounding atmosphere to push air into the vacuum tank, harnessing the velocity of the jet of air as it does so.
As for solar technologies an often overlooked solar technology is the use of solar concentrated thermal technology, a mirror dish is used for instance to focus solar energy on a stirling engine which can then convert the energy into mechanical and electrical energy. The advantages of this is the technology avoids the needs for expensive photovoltaic production of large surface areas. A version of this also focuses a larger amount of solar energy on a smaller photovoltaic cell using the dish.
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.
I am not anti-systemd and that systemd is built around a modular architecture usign DBUS is a point that needs to be made clearly to defuse arguments against it. I do agree that many arguments people are using against it are disinformation and deceptive.
Translating to C would not impose a limitation on the language features of C++, its possible to generate whatever C code you need to support C++ features. Using an LALR parser would introduce limitations on language design, however. This was once very common.
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.
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.
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.
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.
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.
Vulkan is not a replacement for OpenGL, by its own admission.
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.
"Hey Ivan, check your six." -- Sidewinder missile jacket patch, showing a Sidewinder driving up the tail of a Russian Su-27