This is one of the really great things about Windows, how it introduces features to people that they really want and need. Having Windows constantly context aware insert product placements directly into peoples lives will really help them be aware of the things they need to spend money on.
Ads are great and anyone who doesn't like this won't know what they are missing. I want to thank Microsoft for introducing this feature to computers. Anyone who doesn't like these features in windows is probably just really stupid.
If it takes military technology to hear a 13 kiloton meteor go off in the ocean, then we have finally found what we need to hear a tree fall in the forest.
I have almost completed producing a full album using only Ardour. We tried Logic and looked at Pro-Tools however, as a band, we made an artistic decision to see where Ardour and Jack would take us because we did not want to invest our time and money learning proprietary tools. Additionally the workflow was something we wanted to alter and being locked into proprietary software meant we had no control over that even though we had the technical expertise to overcome issues.
We are a live band with instruments (drums, guitars, bass, vocals and a lot of sweat) recorded, using Ardour on hardware tuned for I/O (ssd, jfs), Linux mint, low latency kernel, rt patches and 16 channels captured from a 24 Channel desk. I threw my friends into the deep end and told them that we were going to record an album. We converted a 3 bedroom house into a studio and recorded over a period of 5 weekends to polish the material we recorded each time. We finalized it with a single recording session in one day after we picked out the songs we wanted to record for the album. They were a bit dubious at first but soon got into it when they could see results.
We used a bunch of different microphones and a number of techniques to capture the sounds we want, I personally feel that the choice of what microphones (which Ardour has allowed me to accumulate and test into an interesting collection), where and how you capture sounds is more important than the software. Ardour just made it possible by just working. We captured all day, no issues and the system was stable. More than that, it really gave my friends the confidence to be a little out there with what they did. It was so much fun but also very hard work.
On the production side I found the Ardour code base to be stable, I use a Xeon 2650, X79, 16Gb ram. I did have one crash, however I had to abuse it pretty hard to get there. It's not perfect, I'm not using the latest version, however it's pretty good. We don't use VSTs and the sonic results so far are amazing with the calf plugins and other open source plugins. I think it is absolutely worth the investment in time to learn Ardour if you are a live band recording music and just want to get on with recording music.
I think Paul Davis is a genius and Jack is a revolution in the way audio production works on a system once you understand how to utilize its power. I don't think we could have achieved the workflow efficiencies we have without Jack or with traditional processes. It's not easy, it's a very heavy workload and I'm hoping I can make some contributions back to the Ardour project with what I have learned by doing this.
The best advise I can give is to cyclically prepare and test all hardware before recording. Agile seems to work pretty good for musicians too.
Of course it's part of the original capabilities, Unix always has been a multiuser, multiprocess system. Init always has been parallel with respect to inittab entries at runlevels. Runlevel scripts are only supposed to pave the way and work in conjunction with binaries or *shell scripts* called from inittab.
Consider these inittab entries in this limited use case:
When the runlevel control scripts complete whatever preparation they need to do, these processes are executed and maintained in parallel for the duration of the runlevel. In runlevel 3 entries tagged "aa" and "cc" are run in parallel. In runlevel 5 entries tagged "aa" and "bb" are run in parallel. Obviously, you can fill the inittab file to the cpu capacity of the machine and init will maintain them for you.
It's so easy to use I'm completely surprised that people don't already know this stuff and know one should be surprised why people who know how to use init don't really like the idea of being forced into using something that is more cumbersome and monolithic.
Is there a use case at the end of this rabbit hole, is that why you are asking?
I do listen to experts. I'll disclose that there is some new work in this area that I am yet to get around to reading.
Perhaps you know of similar works in other Nuclear Industry effluents, like plutonium or strontium 90 or the other more energetic radio-isotopes you have to study that you can refer me to. I saw Tritium as the one that is often cited as "benign" as a good place to start.
According to these scientific studies on the effects of tritium, your comic is an oversimplification of how Nuclear Industry effluents (Tritium in this case) behave.
Tritium is biologically mutagenic *because* it's a low energy emitter. This characteristic makes readily absorbed by surrounding cells. The available evidence from studies conducted journal a list of effects. From those works;
Tritium can be inhaled, ingested, or absorbed through skin. Eating food containing 3H can be even more damaging than drinking 3H bound in water. Consequently, an estimated radiation dose based only on ingestion of tritiated water may underestimate the health effects if the person has also consumed food contaminated with tritium. (Komatsu)
Studies indicate that lower doses of tritium can cause more cell death (Dobson, 1976), mutations (Ito) and chromosome damage (Hori) per dose than higher tritium doses. Tritium can impart damage which is two or more times greater per dose than either x-rays or gamma rays.
(Straume) (Dobson, 1976) There is no evidence of a threshold for damage from 3H exposure; even the smallest amount of tritium can have negative health impacts. (Dobson, 1974) Organically bound tritium (tritium bound in animal or plant tissue) can stay in the body for 10 years or more.
It's often said "of all the elements in nuclear waste tritium is one of the more harmless ones" and while it's more benign than most other radioactive effluents it's toxicity should not be under-estimated.
Tritium can cause mutations, tumors and cell death. (Rytomaa) Tritiated water is associated with significantly decreased weight of brain and genital tract organs in mice (Torok) and can cause irreversible loss of female germ cells in both mice and monkeys even at low concentrations. (Dobson, 1979) (Laskey) Tritium from tritiated water can become incorporated into DNA, the molecular basis of heredity for living organisms. DNA is especially sensitive to radiation. (Hori) A cell's exposure to tritium bound in DNA can be even more toxic than its exposure to tritium in water. (Straume)(Carr)
First, as an isotope of hydrogen (the cell's most ubiquitous element), tritium can be incorporated into essentially all portions of the living machinery; and it is not innocuous -- deaths have occurred in industry from occupational overexposure. R. Lowry Dobson, MD, PhD. (1979)
References;
Komatsu, K and Okumura, Y. Radiation Dose to Mouse Liver Cells from Ingestion of Tritiated Food or Water. Health Physics. 58. 5:625-629. 1990.
Dobson, RL. The Toxicity of Tritium. International Atomic Energy Agency symposium, Vienna: Biological Implications of Radionuclides Released from Nuclear Industries v. 1: 203. 1979.
Hori, TA and Nakai, S. Unusual Dose-Response of Chromosome Aberrations Induced in Human Lymphocytes by Very Low Dose Exposures to Tritium. Mutation Research. 50: 101-110. 1978.
Straume, T and Carsten, AL.Tritium Radiobiology and Relative Biological Effectiveness. Health Physics. 65 (6):657-672; 1993. [This special issue of Health Physics is entirely devoted to Tritium]
Laskey, JW, et al. Some Effects of Lifetime Parental Exposure to Low Levels of Tritium on the F2 Generation. Radiation Research.56:171-179. 1973.
Rytomaa, T, et al. Radiotoxicity of Tritium-Labelled Molecules. International Atomic Energy Agency symposium,Vienna: Biological Implications of Radionuclides Released from Nuclear Industries v. 1: 339. 1979.
The issue is that these agencies want unlimited access without control because they want exclude themselves from due process of law. They consider themselves above the principles of democracy.
But the failure of a mistimed valve is way more catastrophic than that of a misfiring injector or spark plug.
This is a cam specific issue due to a stuck valve. If a valve gets stuck or the timing belt snaps then the piston will hit and bend the valve.
Even if an electrically actuated valve system was to be used in production I'd expect it either to be supported by a backup mechanical system or to be designed never to interfere with the volume occupied by a piston.
There is every reason to think that it could be done that way. The issue with opening and closing the valves is the Volumetric Efficiency of an engine. Cams try to do this by opening the valves into the piston space because the duration that the valve will be open for is only optimal for one range of RPM.
A solenoid valve system could hold the valve open for longer at a much shallower depth and vary *when* the valve is open to accommodate this very scenario.
It's not just systemd that is destroying SysV. It's also Solaris, OS X, PC-BSD, and FreeBSD -- we can probably say well over 90% of the major Unix platforms.
Well you won't get disagreement from me on that, systemd advocates do have a point about the rc system, it's horrible and not used as it was intended. rc stands for runlevel control it's job is to prepare the way for all processes that init maintain in that runlevel, not actually do init's job. That's about as appropriate as having domain logic in UI code.
Last night I started figuring out tools to demistify init using small tools only. I was wondering what an init cli would look like.
The critical failure of SysV init is the pidfile. Yes, pidfiles almost always match the service they are supposed to, but this is not something that should ever have been left to userland. Similarly, daemonizing a process should never have been left up to script writers, given that glibc doesn't even do it correctly.
Well this is exactly what init is for and using a pid file is a big example of what I was talking about in my previous post because it is the most common "mis-use case" I know many people use. pidfiles are unnecessary, using one means you are trying to do what init already does better than you can do it.
They haven't mastered init's parallel nature and they are not thinking in terms of a "state" machine. rc is sequential and that's why boots take so long.
The problem with UNIX is that it makes the barrier for failure really high by tolerating this bad design. Those who endure this nightmare might be pleasantly surprised about how much easier init makes this for them if you use it the right way.
systemd would have attracted no more attention than upstart when it was released. It *is* init, it has a superset of the same features, only with an event-driven model,
I don't think it is init's job to be processing events, it is a process handler. However I think you'll find this is what ondemand runlevels are designed to service, because the event may require root to maintain the process. An event listener messages the event handler provides the necessary abstraction from userland. The event handler tells init to change the behaviour of the system in response to an event and the on demand runlevel executes the process systemwide.
The argument with systemd isn't an argument about how best to manage services, it's about technical debt so entrenched that people think that's the way it's supposed to be.
Indeed, I think people are just afraid of editing inittab files and issuing kill signals to init. I don't see technical debt in init though. I see plenty in the runlevel control system because init hasn't been fully utilized. Perhaps the knowledge about how to use init properly has been inaccessible.
I'm certain anyone here who supports large enterprise customers would like to have the systemd developers attend their Post Incident Review because of jounalctl's behaviour. If systemd is better than init, I want to know why. I'm still testing systemd so I'm still not sure but trying to keep an open mind.
You may not have reached the limits of inittab, but other people with different use-cases have
Perhaps, however I'm sincere and curious about that, if I'm wrong it could be a compelling use case for systemd, that's why I shouted out for people to throw a use case at me.
I miss the simplicity of the bsd-like init config scripts sitting on top of SysV in Arch, before they adopted systemd. So much could be configured from rc.conf, the daemon commands were simple, and I never had problems booting.
gah
Yielding the power of UNIX has always laid in creating your systems inittab file, I thought everyone did that. I used to look upon rc scripts as an unnecessary complication of the system and wondered why they were there. If a service needs to be up, init makes sure it's up. If you want to take the service down, tell init to take it down. vim/etc/inittab && kill -1 1 then get on with the rest of your day.
Network services, is good example, a shell script handled by rc, is a prime candidate for an init controlled service. Getting init to kick of printer services after a short delay so that CPU time is focus on providing a GUI to a user could be another. Messaging system is a perfect example.
What about using runlevel 4 for your customised system state, 3 for shell level maintenance, 5 for GUI level maintenance? How about an ondemand runlevel?
Just learn how to use init *actions*, which is a lot simpler than systemd. Simple, scarily powerful and totally under utilised in Linux.
After spending some time with systemd writing unit files and playing around with jounalctl my sense is that this entire situation would be resolved with a set of small tools that manipulate inittab files properly that could support a GUI based inittab editor, thus complementing/completing the original design philosophy with a small maintainable set of tools that rpm, yast, apt-get could utilize. I wonder if people would be interested in such a thing? Perhaps it's time to contact the Devuan people.
I can agree with systemd supporters that the rc system is crap, however that still isn't init and systemd is as monolithic as the rc system, except it's compiled. I think the main objection to the idea of systemd is init is a core idea of the UNIX Operating System that is powerful. I've never seen a Linux distribution that uses init properly and essentially the argument is to replace a core idea of a stable operating system platform because people just don't understand how to use UNIX's most powerful concept one step removed from the kernel. Fast and lean!
The funny thing is, after all these years, I still haven't got everything I can get out of init. Do you understand what you are destroying systemd guys?
SysV and the flusterfuck dyslexic script hackery behind SysV was a constant nightmare with a mountain hardware complaints leading back to it.
Even so the clusterfuck of rc scripts in most redhat derivatives was Red-Hat's creation. People aren't using init, via inittab, properly and now the reason cited to replace init is because the rc system, and the script hackery behind it created by red-hat is disliked. Keh?
Wouldn't a better rc system work better?
Here is a thought, why not learn how to use the shell properly so that shell hackery is not required. Or another idea, learn how to implement design patterns in bash/sh/ksh/zsh. Init is a simple elegant idea, people are arguing for it's removal because they aren't skilled enough writing *shell scripts*. It seems a bit silly to me that people who can't write something so simple have any business modifying the way the OS initializes.
It would be great to get Ken Thopson's opinion on the situation.
However, since we have the attention of many systemd advocates, can someone please throw a use case at me that init doesn't satisfy that systemd does? I'm really trying to understand why it is supposed to be better than something that is as tested as init. I don't mind using it, but why it is supposed to be so compelling?
or that you should trust me solely based on my credentials,
I'm a reasonable, smart guy. I trust facts and evidence, science, where available, any published law I can find, policy, organizational charters, studies, conference minutes. I'll consider any information you present, including its likelyhood for bias.
but since you "called me out" for not understanding it I will inform you that I am a trained nuclear engineer working in the nuclear industry,
Great, I'm happy to defer to your knowledge of reactor operations if I want to learn more about Accident Sequence Precursors or Basis Design Issues. However I don't see how that is relevant if we are talking about biology and the way radioisotopes are absorbed and concentrated in the food chain.
Are the metabolic processes that absorb radio-isotopes into the food chain part of the studies to be a Nuclear Engineer?
I was calling you out on the oversimplification of the facts. To highlight the oversimplification, where does your comic make the destinction between internal and external radiation exposure, or what happens to the energetic levels of a radio isotope inside the body when it is organically bound?
By not disclosing your position, you are not disclosing your bias towards defending the interests of your profession and employer when providing it. It seems pretty disingenuous to me to placate everyone from an implied position of independence, whilst maintaining a undisclosed bias. And being pretty rude and condescending about it too.
I note your freak, quick to judge I see. I have some doubt that you can conduct a civilized conversation without acting if everyone is stupid for not understanding your point of view because your having a hissy fit when a differing one is offered. Your not the only smart person here and if you don't have the patience to defend your point of veiw when challenged then it must be pretty fragile.
I'll get to answering your other points as I get time over the next couple of days.
All of the waste of fission reactors are contained in the cladding. You actually get more radiation exposure living next to a coal plant, since the heavy metals are released into the atmosphere.
Which is also has not been subjected to any enrichment by nuclear industry processes. I specifically referred to artificially made elements.
but you cannot say that the environment has any alpha-emitting radionuclides that you can accidentally get into your body and worry about.
Yes I can, I just don't know how much of them Fukushima, Chernobyl or other accidents have released.
TL:DR stop spreading irrational fear about nuclear fission power plants.
Just because you don't understand it, doesn't mean it's irrational. What you're doing is how social proof spreads ignorance.
If you were discussing what an iron analogue was and how bio-accumulation in the environment worked, then perhaps you could say that. From my perspective though it appears that you are skipping the complexity of how that works and instead transmuting your idealized version into a belief system that has little to do with the reality of how radio-isotopes are concentrated in the food chain.
Ignoring a body of knowledge doesn't mean it doesn't exist.
Actually you are being unintentionally misleading. Certain radioisotopes can be ingested via metabolic processes, for example plutonium chloride is very water soluble and is readily absorbed. Within the body the radioisotope continues to emit radiation and some become organically bound to cells and other parts of the body and that's when the damage occurs, cumulative, slowly and, over time.
Dempending on what and where the radioisotope gets deposited, it eventually means cancerous death for some however it can also mean disease that manifests in the next generation ( transgenic) because of damage it does to the DNA of unborn children.
That's why these artificially made elements don't belong in the environment and keeping them contained is a question of how good our engineering is.
Personally I'm hoping Fusion works because it will produce far less waste products than the industrial processes of Fission reactors.
Radionuclides emit radiation. What you need to understand is the behaviour of radionuclides in the environment. Until you do xkcd comics are only going to explain external radiation exposure to you. The difference between internal and external exposure is one damages you and the other probably won't do much of anything to you.
What radionuclides do in the body and how they get there is the understanding required, you insensitive clod.
What would a union do? Strikes don't happen at government-regulated utilities the same way they do at a wholly private company.
They would lobby politicians at state and federal levels so that strikes are unnecessary.
Another thing I imagine a union *could* do is negotiate with employers so that H1B visas are implemented more equitably. There maybe a genuine need for them however that shouldn't mean that young local talent should be denied opportunities to get a foot hold with their careers, a union *could* negotiate on their behalf. It could also anonymously by-pass gag orders such as these so that the truth about the conditions are know. It could also look at stale, but talented people and identify what training the need to secure new opportunities.
Whilst it has been unpopular to talk about IT unions it's probably time to step out of the outmoded thinking that suggests that any IT union would be the same as a union that deals with unskilled professionals. We are not, and I can't see IT professionals in a picket line. I can see them being smart enough to take a long view with issues and have an union defend their interests. Individually we have no power and the types of laws we are being subjected to suggest we are not taken seriously as other professionals who have organizations that look after their political interests.
I feel it's a little naive to think we are all so special and great that we don't need anyone arguing for us within the upper echelons of power. Taking the worst fears of what a union is and suggesting that is an argument for not having them is why we are in the situation we are now. We should be looking to the behaviors we want in a union and charter it so that's how it behaves. We either shape our future or have it shaped for us.
UEFI is accessible for change. Note the standard doesn't demand that 'getting bricked' be possible, it's the firmware developer implementations that have issues.
Right now the efi variables are normal files:
$ ls/sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c -l
-rw-r--r-- 1 root root 57 Jan 22 09:58/sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Thanks, I've not paid enough attention to this, I'm glad it didn't catch me.
So my proposal would be either to make each something like a character device, with special ioctl for 'deletion', or a normal file, except ignore 'unlink()' and provide a separate character device with ioctl to remove the variables, or some 'echo delete Boot000 > whatever' type interface. The latter is probably the best all things considered.
It seems reasonable, especially as it would offer a degree of protection against shitty UEFI implementations.
The whole acess to the variables space is already an abstraction, so efivars can do whatever they want (though would break downstream utilit(ies) expecting to be able to unlink, but I think that's worth the work. A utility can be backward compatible by checking for existence of new interface, and falling back to unlink should that new remove interface be missing.
Indeed, breaking a few utilities is a small price to pay so you can't brick a motherboard. Software can change.
I think we are talking about different scenarios. I appreciate the description of your locale, mine is different.
cats didn't suddenly arrive in a predator-free situation (exceptions noted for isolated islands where medium and larger predators failed to arrive or evolve -- remember the species already there invaded too, if much longer ago).
This is exactly what has happened in my locale.
And cats generally don't survive away from human influence. Other predators think they're very tasty and all too easily caught. Cripes, in the desert I couldn't grow cats fast enough to keep the owl and coyote buffet stocked. Every cat that went outside the fence got eaten.
Where I live, every cat that gets into the wild, breeds more cats. I used to hunt to help the farmers out (mainly with wild rabbits, goats, pigs and foxes) and they would carry a ball pean hammer to deal with the nasty little bastards.
Cats are very successful predators here and there are too many of them killing off the parrots, marsupials.
And considering that in an urban or suburban setting you will have either free-roaming cats, or assloads of rats and mice, which do you choose??
We have several species of owls, kookaburras, kingfishers, hawks, magpies and surprisingly, ducks, that all love to eat mice and rats
Maybe you'd prefer to import weasels, foxes, and skunks. Rabies ahoy!!
We have a lot of foxes, pythons already. Hunting fox is pretty hard and kind of funny
Funny how the same people who decry free-roaming cats usually support "wolf reintroduction" in the western U.S.
I don't. I think it's fucking stupid. Here it's people saying that about saltwater crocodiles and if you've ever seen a 5 metre croc jump out of the water you understand primal fear. So wolf's - no - it's a bad idea as well.
Slashdot Mirror
So you approve of Microsoft as the great stalker boyfriend? :)
Of course. It's exciting! Someone that knows *everything* about me, wants me all the time. I'll never be alone again. I'm so happy.
This is one of the really great things about Windows, how it introduces features to people that they really want and need. Having Windows constantly context aware insert product placements directly into peoples lives will really help them be aware of the things they need to spend money on.
Ads are great and anyone who doesn't like this won't know what they are missing. I want to thank Microsoft for introducing this feature to computers. Anyone who doesn't like these features in windows is probably just really stupid.
If it takes military technology to hear a 13 kiloton meteor go off in the ocean, then we have finally found what we need to hear a tree fall in the forest.
I have almost completed producing a full album using only Ardour. We tried Logic and looked at Pro-Tools however, as a band, we made an artistic decision to see where Ardour and Jack would take us because we did not want to invest our time and money learning proprietary tools. Additionally the workflow was something we wanted to alter and being locked into proprietary software meant we had no control over that even though we had the technical expertise to overcome issues.
We are a live band with instruments (drums, guitars, bass, vocals and a lot of sweat) recorded, using Ardour on hardware tuned for I/O (ssd, jfs), Linux mint, low latency kernel, rt patches and 16 channels captured from a 24 Channel desk. I threw my friends into the deep end and told them that we were going to record an album. We converted a 3 bedroom house into a studio and recorded over a period of 5 weekends to polish the material we recorded each time. We finalized it with a single recording session in one day after we picked out the songs we wanted to record for the album. They were a bit dubious at first but soon got into it when they could see results.
We used a bunch of different microphones and a number of techniques to capture the sounds we want, I personally feel that the choice of what microphones (which Ardour has allowed me to accumulate and test into an interesting collection), where and how you capture sounds is more important than the software. Ardour just made it possible by just working. We captured all day, no issues and the system was stable. More than that, it really gave my friends the confidence to be a little out there with what they did. It was so much fun but also very hard work.
On the production side I found the Ardour code base to be stable, I use a Xeon 2650, X79, 16Gb ram. I did have one crash, however I had to abuse it pretty hard to get there. It's not perfect, I'm not using the latest version, however it's pretty good. We don't use VSTs and the sonic results so far are amazing with the calf plugins and other open source plugins. I think it is absolutely worth the investment in time to learn Ardour if you are a live band recording music and just want to get on with recording music.
I think Paul Davis is a genius and Jack is a revolution in the way audio production works on a system once you understand how to utilize its power. I don't think we could have achieved the workflow efficiencies we have without Jack or with traditional processes. It's not easy, it's a very heavy workload and I'm hoping I can make some contributions back to the Ardour project with what I have learned by doing this.
The best advise I can give is to cyclically prepare and test all hardware before recording. Agile seems to work pretty good for musicians too.
Of course it's part of the original capabilities, Unix always has been a multiuser, multiprocess system. Init always has been parallel with respect to inittab entries at runlevels. Runlevel scripts are only supposed to pave the way and work in conjunction with binaries or *shell scripts* called from inittab.
Consider these inittab entries in this limited use case:
When the runlevel control scripts complete whatever preparation they need to do, these processes are executed and maintained in parallel for the duration of the runlevel. In runlevel 3 entries tagged "aa" and "cc" are run in parallel. In runlevel 5 entries tagged "aa" and "bb" are run in parallel. Obviously, you can fill the inittab file to the cpu capacity of the machine and init will maintain them for you.
It's so easy to use I'm completely surprised that people don't already know this stuff and know one should be surprised why people who know how to use init don't really like the idea of being forced into using something that is more cumbersome and monolithic.
Is there a use case at the end of this rabbit hole, is that why you are asking?
I do listen to experts. I'll disclose that there is some new work in this area that I am yet to get around to reading.
Perhaps you know of similar works in other Nuclear Industry effluents, like plutonium or strontium 90 or the other more energetic radio-isotopes you have to study that you can refer me to. I saw Tritium as the one that is often cited as "benign" as a good place to start.
According to these scientific studies on the effects of tritium, your comic is an oversimplification of how Nuclear Industry effluents (Tritium in this case) behave.
Tritium is biologically mutagenic *because* it's a low energy emitter. This characteristic makes readily absorbed by surrounding cells. The available evidence from studies conducted journal a list of effects. From those works;
Tritium can be inhaled, ingested, or absorbed through skin. Eating food containing 3H can be even more damaging than drinking 3H bound in water. Consequently, an estimated radiation dose based only on ingestion of tritiated water may underestimate the health effects if the person has also consumed food contaminated with tritium. (Komatsu)
Studies indicate that lower doses of tritium can cause more cell death (Dobson, 1976), mutations (Ito) and chromosome damage (Hori) per dose than higher tritium doses. Tritium can impart damage which is two or more times greater per dose than either x-rays or gamma rays.
(Straume) (Dobson, 1976) There is no evidence of a threshold for damage from 3H exposure; even the smallest amount of tritium can have negative health impacts. (Dobson, 1974) Organically bound tritium (tritium bound in animal or plant tissue) can stay in the body for 10 years or more.
It's often said "of all the elements in nuclear waste tritium is one of the more harmless ones" and while it's more benign than most other radioactive effluents it's toxicity should not be under-estimated.
Tritium can cause mutations, tumors and cell death. (Rytomaa) Tritiated water is associated with significantly decreased weight of brain and genital tract organs in mice (Torok) and can cause irreversible loss of female germ cells in both mice and monkeys even at low concentrations. (Dobson, 1979) (Laskey) Tritium from tritiated water can become incorporated into DNA, the molecular basis of heredity for living organisms. DNA is especially sensitive to radiation. (Hori) A cell's exposure to tritium bound in DNA can be even more toxic than its exposure to tritium in water. (Straume)(Carr)
First, as an isotope of hydrogen (the cell's most ubiquitous element), tritium can be incorporated into essentially all portions of the living machinery; and it is not innocuous -- deaths have occurred in industry from occupational overexposure. R. Lowry Dobson, MD, PhD. (1979)
References;
Good luck finding a jury that will send someone to jail when no harm has been done. Now everyone, please bone up on jury nullification.
Won't the Investor State Dispute Settlement clauses change the way they process these cases?
The issue is that these agencies want unlimited access without control because they want exclude themselves from due process of law. They consider themselves above the principles of democracy.
But the failure of a mistimed valve is way more catastrophic than that of a misfiring injector or spark plug.
This is a cam specific issue due to a stuck valve. If a valve gets stuck or the timing belt snaps then the piston will hit and bend the valve.
Even if an electrically actuated valve system was to be used in production I'd expect it either to be supported by a backup mechanical system or to be designed never to interfere with the volume occupied by a piston.
There is every reason to think that it could be done that way. The issue with opening and closing the valves is the Volumetric Efficiency of an engine. Cams try to do this by opening the valves into the piston space because the duration that the valve will be open for is only optimal for one range of RPM.
A solenoid valve system could hold the valve open for longer at a much shallower depth and vary *when* the valve is open to accommodate this very scenario.
We've seen the results of an occasional error in that work!!!
It's not just systemd that is destroying SysV. It's also Solaris, OS X, PC-BSD, and FreeBSD -- we can probably say well over 90% of the major Unix platforms.
Well you won't get disagreement from me on that, systemd advocates do have a point about the rc system, it's horrible and not used as it was intended. rc stands for runlevel control it's job is to prepare the way for all processes that init maintain in that runlevel, not actually do init's job. That's about as appropriate as having domain logic in UI code.
Last night I started figuring out tools to demistify init using small tools only. I was wondering what an init cli would look like.
The critical failure of SysV init is the pidfile. Yes, pidfiles almost always match the service they are supposed to, but this is not something that should ever have been left to userland. Similarly, daemonizing a process should never have been left up to script writers, given that glibc doesn't even do it correctly.
Well this is exactly what init is for and using a pid file is a big example of what I was talking about in my previous post because it is the most common "mis-use case" I know many people use. pidfiles are unnecessary, using one means you are trying to do what init already does better than you can do it.
They haven't mastered init's parallel nature and they are not thinking in terms of a "state" machine. rc is sequential and that's why boots take so long. The problem with UNIX is that it makes the barrier for failure really high by tolerating this bad design. Those who endure this nightmare might be pleasantly surprised about how much easier init makes this for them if you use it the right way.
systemd would have attracted no more attention than upstart when it was released. It *is* init, it has a superset of the same features, only with an event-driven model,
I don't think it is init's job to be processing events, it is a process handler. However I think you'll find this is what ondemand runlevels are designed to service, because the event may require root to maintain the process. An event listener messages the event handler provides the necessary abstraction from userland. The event handler tells init to change the behaviour of the system in response to an event and the on demand runlevel executes the process systemwide.
The argument with systemd isn't an argument about how best to manage services, it's about technical debt so entrenched that people think that's the way it's supposed to be.
Indeed, I think people are just afraid of editing inittab files and issuing kill signals to init. I don't see technical debt in init though. I see plenty in the runlevel control system because init hasn't been fully utilized. Perhaps the knowledge about how to use init properly has been inaccessible.
I'm certain anyone here who supports large enterprise customers would like to have the systemd developers attend their Post Incident Review because of jounalctl's behaviour. If systemd is better than init, I want to know why. I'm still testing systemd so I'm still not sure but trying to keep an open mind.
You may not have reached the limits of inittab, but other people with different use-cases have
Perhaps, however I'm sincere and curious about that, if I'm wrong it could be a compelling use case for systemd, that's why I shouted out for people to throw a use case at me.
Landmines kill little kids without asking. Do we want more things killing automatically?
I miss the simplicity of the bsd-like init config scripts sitting on top of SysV in Arch, before they adopted systemd. So much could be configured from rc.conf, the daemon commands were simple, and I never had problems booting. gah
Yielding the power of UNIX has always laid in creating your systems inittab file, I thought everyone did that. I used to look upon rc scripts as an unnecessary complication of the system and wondered why they were there. If a service needs to be up, init makes sure it's up. If you want to take the service down, tell init to take it down. vim /etc/inittab && kill -1 1 then get on with the rest of your day.
Network services, is good example, a shell script handled by rc, is a prime candidate for an init controlled service. Getting init to kick of printer services after a short delay so that CPU time is focus on providing a GUI to a user could be another. Messaging system is a perfect example.
What about using runlevel 4 for your customised system state, 3 for shell level maintenance, 5 for GUI level maintenance? How about an ondemand runlevel?
Just learn how to use init *actions*, which is a lot simpler than systemd. Simple, scarily powerful and totally under utilised in Linux.
After spending some time with systemd writing unit files and playing around with jounalctl my sense is that this entire situation would be resolved with a set of small tools that manipulate inittab files properly that could support a GUI based inittab editor, thus complementing/completing the original design philosophy with a small maintainable set of tools that rpm, yast, apt-get could utilize. I wonder if people would be interested in such a thing? Perhaps it's time to contact the Devuan people.
I can agree with systemd supporters that the rc system is crap, however that still isn't init and systemd is as monolithic as the rc system, except it's compiled. I think the main objection to the idea of systemd is init is a core idea of the UNIX Operating System that is powerful. I've never seen a Linux distribution that uses init properly and essentially the argument is to replace a core idea of a stable operating system platform because people just don't understand how to use UNIX's most powerful concept one step removed from the kernel. Fast and lean!
The funny thing is, after all these years, I still haven't got everything I can get out of init. Do you understand what you are destroying systemd guys?
Has anyone got a use case yet?
SysV and the flusterfuck dyslexic script hackery behind SysV was a constant nightmare with a mountain hardware complaints leading back to it.
Even so the clusterfuck of rc scripts in most redhat derivatives was Red-Hat's creation. People aren't using init, via inittab, properly and now the reason cited to replace init is because the rc system, and the script hackery behind it created by red-hat is disliked. Keh?
Wouldn't a better rc system work better?
Here is a thought, why not learn how to use the shell properly so that shell hackery is not required. Or another idea, learn how to implement design patterns in bash/sh/ksh/zsh. Init is a simple elegant idea, people are arguing for it's removal because they aren't skilled enough writing *shell scripts*. It seems a bit silly to me that people who can't write something so simple have any business modifying the way the OS initializes.
It would be great to get Ken Thopson's opinion on the situation.
However, since we have the attention of many systemd advocates, can someone please throw a use case at me that init doesn't satisfy that systemd does? I'm really trying to understand why it is supposed to be better than something that is as tested as init. I don't mind using it, but why it is supposed to be so compelling?
but that is exactly what you are going to do.
I'm a reasonable, smart guy. I trust facts and evidence, science, where available, any published law I can find, policy, organizational charters, studies, conference minutes. I'll consider any information you present, including its likelyhood for bias.
Great, I'm happy to defer to your knowledge of reactor operations if I want to learn more about Accident Sequence Precursors or Basis Design Issues. However I don't see how that is relevant if we are talking about biology and the way radioisotopes are absorbed and concentrated in the food chain. Are the metabolic processes that absorb radio-isotopes into the food chain part of the studies to be a Nuclear Engineer?
I was calling you out on the oversimplification of the facts. To highlight the oversimplification, where does your comic make the destinction between internal and external radiation exposure, or what happens to the energetic levels of a radio isotope inside the body when it is organically bound?
By not disclosing your position, you are not disclosing your bias towards defending the interests of your profession and employer when providing it. It seems pretty disingenuous to me to placate everyone from an implied position of independence, whilst maintaining a undisclosed bias. And being pretty rude and condescending about it too.
I note your freak, quick to judge I see. I have some doubt that you can conduct a civilized conversation without acting if everyone is stupid for not understanding your point of view because your having a hissy fit when a differing one is offered. Your not the only smart person here and if you don't have the patience to defend your point of veiw when challenged then it must be pretty fragile.
I'll get to answering your other points as I get time over the next couple of days.
All of the waste of fission reactors are contained in the cladding. You actually get more radiation exposure living next to a coal plant, since the heavy metals are released into the atmosphere.
Which is also has not been subjected to any enrichment by nuclear industry processes. I specifically referred to artificially made elements.
but you cannot say that the environment has any alpha-emitting radionuclides that you can accidentally get into your body and worry about.
Yes I can, I just don't know how much of them Fukushima, Chernobyl or other accidents have released.
TL:DR stop spreading irrational fear about nuclear fission power plants.
Just because you don't understand it, doesn't mean it's irrational. What you're doing is how social proof spreads ignorance.
If you were discussing what an iron analogue was and how bio-accumulation in the environment worked, then perhaps you could say that. From my perspective though it appears that you are skipping the complexity of how that works and instead transmuting your idealized version into a belief system that has little to do with the reality of how radio-isotopes are concentrated in the food chain.
Ignoring a body of knowledge doesn't mean it doesn't exist.
What is your problem with my statement?
It's an over-simplification. The reality is more complex.
Clean is misleading here
But we need to get around the same stigma that has hamstrung fission reactors - that "radioactive" means "cancerous death" to the electorate.
Snowballs thrown... no, YOU'RE misleading!!!
But seriously, people like you are the true problem. Everyone else, let's try to understand the actual facts about radiation. Obligatory xkcd:
http://xkcd.com/radiation/
Actually you are being unintentionally misleading. Certain radioisotopes can be ingested via metabolic processes, for example plutonium chloride is very water soluble and is readily absorbed. Within the body the radioisotope continues to emit radiation and some become organically bound to cells and other parts of the body and that's when the damage occurs, cumulative, slowly and, over time.
Dempending on what and where the radioisotope gets deposited, it eventually means cancerous death for some however it can also mean disease that manifests in the next generation ( transgenic) because of damage it does to the DNA of unborn children.
That's why these artificially made elements don't belong in the environment and keeping them contained is a question of how good our engineering is.
Personally I'm hoping Fusion works because it will produce far less waste products than the industrial processes of Fission reactors.
Everyone else, let's try to understand the actual facts about radiation. Obligatory xkcd:
http://xkcd.com/radiation/
Radionuclides emit radiation. What you need to understand is the behaviour of radionuclides in the environment. Until you do xkcd comics are only going to explain external radiation exposure to you. The difference between internal and external exposure is one damages you and the other probably won't do much of anything to you.
What radionuclides do in the body and how they get there is the understanding required, you insensitive clod.
What would a union do? Strikes don't happen at government-regulated utilities the same way they do at a wholly private company.
They would lobby politicians at state and federal levels so that strikes are unnecessary.
Another thing I imagine a union *could* do is negotiate with employers so that H1B visas are implemented more equitably. There maybe a genuine need for them however that shouldn't mean that young local talent should be denied opportunities to get a foot hold with their careers, a union *could* negotiate on their behalf. It could also anonymously by-pass gag orders such as these so that the truth about the conditions are know. It could also look at stale, but talented people and identify what training the need to secure new opportunities.
Whilst it has been unpopular to talk about IT unions it's probably time to step out of the outmoded thinking that suggests that any IT union would be the same as a union that deals with unskilled professionals. We are not, and I can't see IT professionals in a picket line. I can see them being smart enough to take a long view with issues and have an union defend their interests. Individually we have no power and the types of laws we are being subjected to suggest we are not taken seriously as other professionals who have organizations that look after their political interests.
I feel it's a little naive to think we are all so special and great that we don't need anyone arguing for us within the upper echelons of power. Taking the worst fears of what a union is and suggesting that is an argument for not having them is why we are in the situation we are now. We should be looking to the behaviors we want in a union and charter it so that's how it behaves. We either shape our future or have it shaped for us.
NO. Change your viewing threshold
This++
UEFI is accessible for change. Note the standard doesn't demand that 'getting bricked' be possible, it's the firmware developer implementations that have issues.
Right now the efi variables are normal files: $ ls /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c -l
-rw-r--r-- 1 root root 57 Jan 22 09:58 /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Thanks, I've not paid enough attention to this, I'm glad it didn't catch me.
So my proposal would be either to make each something like a character device, with special ioctl for 'deletion', or a normal file, except ignore 'unlink()' and provide a separate character device with ioctl to remove the variables, or some 'echo delete Boot000 > whatever' type interface. The latter is probably the best all things considered.
It seems reasonable, especially as it would offer a degree of protection against shitty UEFI implementations.
The whole acess to the variables space is already an abstraction, so efivars can do whatever they want (though would break downstream utilit(ies) expecting to be able to unlink, but I think that's worth the work. A utility can be backward compatible by checking for existence of new interface, and falling back to unlink should that new remove interface be missing.
Indeed, breaking a few utilities is a small price to pay so you can't brick a motherboard. Software can change.
cats didn't suddenly arrive in a predator-free situation (exceptions noted for isolated islands where medium and larger predators failed to arrive or evolve -- remember the species already there invaded too, if much longer ago).
This is exactly what has happened in my locale.
And cats generally don't survive away from human influence. Other predators think they're very tasty and all too easily caught. Cripes, in the desert I couldn't grow cats fast enough to keep the owl and coyote buffet stocked. Every cat that went outside the fence got eaten.
Where I live, every cat that gets into the wild, breeds more cats. I used to hunt to help the farmers out (mainly with wild rabbits, goats, pigs and foxes) and they would carry a ball pean hammer to deal with the nasty little bastards.
Cats are very successful predators here and there are too many of them killing off the parrots, marsupials.
And considering that in an urban or suburban setting you will have either free-roaming cats, or assloads of rats and mice, which do you choose??
We have several species of owls, kookaburras, kingfishers, hawks, magpies and surprisingly, ducks, that all love to eat mice and rats
Maybe you'd prefer to import weasels, foxes, and skunks. Rabies ahoy!!
We have a lot of foxes, pythons already. Hunting fox is pretty hard and kind of funny
Funny how the same people who decry free-roaming cats usually support "wolf reintroduction" in the western U.S.
I don't. I think it's fucking stupid. Here it's people saying that about saltwater crocodiles and if you've ever seen a 5 metre croc jump out of the water you understand primal fear. So wolf's - no - it's a bad idea as well.