If only this was because Tepco was wilfully concealing the radiation level in order to save money, but this is likely to be caused by symptomatic incompetence on so many levels in Tepco. One wonders what stupendous errors and failures Tepco will provide in the future.
Instead of progressing, the situation at the Fukushima plant seems get worse day for day; the water tanks are corroding and leaking, the local radiation levels seems to break new records every month, the ground beneath reactor 4 is apparently unstable, no one have a clear picture of what exactly is going on inside the reactor buildings because of the massive radiation, and up until now, only "band aid" work and cleaning have been done; the most difficult and dangerous job of removing the spent fuel rods have barely begun, and is likely to take many years.
Oh, and the same report cites a scientific paper on how new magnitude 7 earthquakes are expected in the area (Tong et al, 2012).
One hopes that Japan are lucky with the wind direction again if the worst should happen, the human and economic consequences of massive radiation cloud spreading over the Japanese inland instead of the sea, are barely comprehensible.
That makes me wonder, if a country has no military, is it illegal to attack that country since it is completely civilian?
No, if you by "attack" means "occupy". However, excessive use of force in occupying a country without any military forces would be illegal. Other things besides excessive use of force could render such an occupation illegal, if it eg. was an unprovoked occupation. (casus belli, aggressive warfare and all that).
An example of an legal occupation of a country without military forces, could be the British occupation of Iceland in 1940.
It is in fact difficult to imagine any war, where the use of chemical weapons wouldn't cause disproportional losses among civilians
Why imagine it when it actually existed? It was WW1. For that matter, most uses of chemical weapons in Iran-Iraq war were on the battlefield against enemy soldiers, as well.
Yes, using chemical weapons in a middle of a populated city guarantees civilian casualties. But then so do sufficiently powerful bombs, which didn't stop NATO from using them in Belgrade in 1998.
I am well aware of WWI. In fact, the use of gas during WWI caused disproportional many civilian deaths compared to the minor military death count. The soldiers quickly got gas masks, had extensive warning systems etc, so gas attacks quickly became ineffective in killing soldiers. The civilians didn't protection and warning systems, and as a consequence often died an large numbers if the wind blew over their village.
So WWI completely support what I wrote.
I am not an expert on the Iran-Irak war, but I can assure you there was many civilian casualties from chemical weapons, either because they ware targeted directly, or as collateral damage. Eg. the Iraqis used mustard gas variations, which doesn't killed immediately (3-5% mortality), but cripples people often for the rest of their reduced life.
People often have a cartoonish perceptions of battlefields, especially WWI, and often have loud opinions about the conduct of the war without ever reading a single scholarly work about it. Your perception that the war was fought far away from civilians are dead wrong, almost 2 millions civilians died in WWI as a direct result of military action.
Second: Bombs that unleash pieces of metal are usually used for specific targets not large populations.
Dresden? Tokyo?
Neither the British nor the US bomber command targeted civilians. The bombing of Dresden ( a major military target, besides being an important railway centre) was part of the official "de-housing" policy, where major cities was bombed in an effort to cripple the German war production; not only would such bombings smash infrastructure like railways depots, they would also hit the many factories and small workshops in the city centres, and finally, it was believed, that by destroying the houses in the cities, they would render them useless as production centres.
One could of course argue, that the difference was very small. But anyhow, the German civilian casualties were small compared to German military losses, showing that the allies didn't wage war against civilians. The German civilian loses from air raids are estimated to be around 400.000 (including allied POWs, foreign labourers, paid or slaves etc.). The combined US/UK loses of airmen where around 150.000. Not an impressive kill ratio if the allied had intended a bomber war against civilians.
It is indeed a very complex issue to which there is no easy one line answers. But there is a sort of logic behind why some weapon systems are banned, and others not, or how even legal weapons can be used in an illegal way.
It is not about some weapons being good or bad, or even the amount of suffering they cause at the individuals affected by them. It is all about keeping military actions under control causing the least amount of suffering among soldiers and civilians in relation to the objectives of the military action. A main reason behind this is the axiom, that war directly targeting civilians is illegal.
The problems with weapons of mass destruction, like chemical weapons, are that their effects can't be controlled; they go where the wind blow. Furthermore, they tend to affect civilians much more than soldiers who often are protected against NBC attacks. All in all, using chemical weapons in a city is effectively targeting civilians, not soldiers.
It is in fact difficult to imagine any war, where the use of chemical weapons wouldn't cause disproportional losses among civilians, so returning to the axiom that wars and military actions directly targeting civilians are illegal, it has some kind of logic, that chemical weapons are banned, while targeted weapons like bombs are not.
Re:I use CentOS for those unless I have no choice
on
Fedora Core May Be Reborn
·
· Score: 3, Insightful
I think a lot of the traditional thinking about servers are changing: VM's, OS-containers, cloud computing means, that the traditional big iron, unchanging OS with hand crafted config files, is receding. Instead all the interesting stuff will happen in mass deployed auto configured VM's, or OS-containers (OpenVZ, LXC etc). There will be VPS's (Virtual Private Servers, served from the cloud), etc. etc.
With services doing live migrations across data centers, and services being configured and executed on a demand only basis, and everything interesting in fleeting VM's and containers, they need for long term feature stable servers may recede;
So while Fedora may not be everyone's choice for a bare metal VM and container server, it may very well be exactly what you want to put inside those VM's and containers. This is why it is important to rethink the Fedora distro. As it is now, its base install very much reflect old style UNIX thinking (nothing wrong with UNIX style, but such servers are not the whole story), that means the base install pulls in stuff like "ed", "tar", "file" etc. While they may nice little standard programs, they may not make sense in a custom VPS.
There are several suggestions what causes the the simultaneous sound, but AFAIK, no one has really made a solid case with measurements to back up their theory.
Oh the 2001 Leonid shower was the best meteor shower I have ever seen. Fireballs streaking across everywhere. An many of them made that crackling/hissing sound when they flew across the sky. It is still unknown how the meteors make that sound and how the noise is able to propagate faster than the speed of sound. (You shouldn't be able to have simultaneous sound with a meteor, since they are +40 km away.). But the crackling sound was widely reported with the 2001 Leonid shower, and AFAIK, scientist have at least actually recorded "noisy" meteors now.
Light pollution is just a sad phenomenon. I have to use a binocular just to see stellar constellations that are easily visible to the naked eye in just semi dark places. I haven't seen the milky way in over a decade.
is the only part of the Calligra Suite I have really tried out (version 2.6.4). It lacks some features necessary for me, but it is a nice lightweight word processor. Its best feature is its tabbed & indexed sidebar. Just moving icon toolbars to the side doesn't work. It seems so logical to use some of that wide screen real estate for toolbars, but in reality it is hard to make sidebars work.
But Calligra Word has got it right: Text instead of icons. Tabbed & indexed to maximize the information, but without losing spatial memory of where functions are. (The main thing I hate about Microsofts "Ribbon").
The Calligra Word "Dockers" is also a very nice concept: they are basically information and toolbar tiles that defaults to the right side. They can either be compressed when tiled together, be tabbed behind each other, or float freely
Looking at the screenshoot of the new 2.7 version, they seem to have improved the toolboxes and their layout even further
Another thing Calligra does very well, is integration with the other components. The Calligra Word has superb drawing and figure making and manipulation abilities, while feeling really fast and lightweight at the same time, no long waits or disc trashing while the drawing component is started etc. It really shines when it comes to making fast one-off DTP/presentation stuff like combining text, figures and pictures, and connecting them with lines.
Of course, old DSL routers and similar. I was thinking too much in traditional network wiring. I can see the reasoning now for speccing 10Mbit as a mandatory minimum, and it probably more or less free to implement if you are going for a 100/1000Mbit nic anyway, so why not be compatible with even corner cases.
I must say, I think EOMA-68 looks very intriguing, it would be exceedingly cool if more devices was made that way.
I mean, does a tablet with a removable CPU card make any sense whatsoever?
Perhaps not for the average consumer, but for the tinkerer it sounds fun; use a A10 ARM CPU card for long battery times (e-reader etc), or a AMD T40E 64-bit x86 dual-core CPU with on-board Radeon 3D graphics (r600) for maximum performance (serving video, ethernet sniffer, games). A I understand it, the EOMA-68 CPU card standard means that the same board potentially can be used in different devices, NAS, tablet, netbook, PVR etc. So it can potentially cut costs when developing a new device, since a lot of the essential stuff is already designed and tested.
It is perhaps a pipe dream, but I would like to live in a world with more FOSS hardware for excellent Linux support. I like the idea of exchangeable hardware done by standard open interfaces.
I would certainly like a tablet with full Linux support, especially with KDE Plasma. Never heard of the "EOMA-68" standard before, but it looks intriguing . Not sure why they specced 10Mbit ethernet support as mandatory minimum for the CPU card. 10Mbit networks must be very rare these days, and the cheap misers who still operates them are unlikely to purchase a tablet. Am I missing something?
Anyway I like the CPU card concept, but I hope the tablet will have GPS, and accelerometer, gyroscope, (digital) compass, or else it has to be cheap.
And how do I do that when, for example, configuring a non-running system from a different system? Like, for instance, setting up embedded systems?
You don't _need_ the *ctl tools to configure a systemd system. Just use "ed -G" (or "vi" if you need some hand holding wysiwyg GUI) to edit the text configuration files. This is no different from sysvinit.
systemd and journald support live remote logging and what not, and if they doesn't all ready support reading of offline log files, they surely will. (not something I have looked at, but perhaps "systemd-journal-remote" is what you need).
The reliance on *ctl apps that have to actually run on the system is a big step back, towards Windows and how you can't really do much about the registry or event logs without a running and compatible Windows system, and for many things THE system it runs on. This is the direction systemd/journald is taking us, and we've seen this before, with AIX. It didn't impress us then, and it doesn't now. Those who don't know (Unix) history are doomed to repeat it.
Having to rely on systemctl is no different than to rely on eg. Bash, vi and all the nice GNU tools, without those, not much can be done.
I see no real world problem in either using the tools on the running system by using eg. ssh, or having a systemd compatible system to analyse log files on a remote system (either offline or live remote logging). In fact, I don't think this is any different from using sysvinit/rsyslog today, except that systemd offers better tools for analysing problems and much better security etc.
They didn't help me when systemd crashed and took with it the entire system. It's built as a card house, with assumptions that things don't go pear shaped, or if they do, you have time to wade through hundreds of configurations in search of the proverbial needle in a haystack. I don't LIKE systems where you put all your eggs in one basket, and for good reason.
This is no different from a failed init that causes a kernel panic. The difference is that systemd now is thoroughly tested on *thousand of machines and keeps improving, so using it to control services will minimize all the dangers that comes from hand editing complicated, often undocumented init scripts.
systemd has superior debugging facilities and is well documented. You can actually systematically analyse what a certain run-level (called target) requires, or tell systemd to spawn a shell if it crashes. It is so much better when it comes to tracking down service/daemon troubles than static scripts.
Sure, there is something to learn about systemd before mastering it, and many people seems to loathe reading about new technology, or just doesn't have much time on their hands to learn new stuff. But neither is a systemd problem, and learning new technology and new ways of doing things, comes with the territory as SA.
Check out all the wonderful stuff one can do with systemd, journald, and all the *ctl tools; completely consistent control and behaviour across every Linux system that uses systemd. No need to learn and relearn dozens of small system peculiarities across distributions for controlling services, working with log-files, getting system info, etc. etc.
systemd is the future because it is such a good idea that most major distributions are switching to it. I will recommend all Linux SA's to put their real or imagined reservations against systemd aside, and start boning up on the subject
There is a lot to learn, not because systemd is complicated, but because it can do so many things, like resource limiting, mounting etc.
And what do you do when something goes wrong? Or you need access from a different arbitrary system?
That sort of questions is exactly why you should read the linked pages. So calm your fuming hate against Poettering and start reading.
I guess your very vague question is something about accessing Journal log files, something you probably think can be problematic since they are binary, right? No worries mate. Syslog is a first class Journal client, you can read all the usual text file stuff in/var/log/* if for some reason journalctl doesn't work, but everything else does. Journal send all messages to syslog, including early boot stuff that syslog couldn't log before.
It is just that when journalctl (and all the other cool *ctl tools) works, it is faster, easier and more secure than the usual chaotic syslog logging. So what is wrong with displaying not only an error message, but also the exact link where the error message is explained and documented? "journalctl -f" instead of "cat/var/log/messages | tail" ? Cryptographic secure logging? That you have an actual guarantee that a message is written by the daemon it claims?
"journalctl", "systemctl" and all the other *ctl tools like localectl, hostnamectl and loginctl, are just wonderful and powerful tools, that promises some kind of consistency when it comes to Linux logging and system information gathering etc.
I think its just cranky old sysadmins that don't like systemd. Its actually quite good and offers several benefits over the old sysvinit.
It's the cranky old sysadmins who keep the servers and internet running. What they say is often important. When someone tries to re-invent Windows Services, AIX smit and Windows Event log, they may grump, but they do so with the experience saying that it wasn't a good idea the last time either.
The problem is that many aren't "cranky old SA's" but just uninformed old gits that refuses to even read up on new technology and flat out denies that there any problems whatsoever with Linux logfiles, and the way Linux handles services (init etc).
Whenever I see systemd or Journal hate here on Slashdot, it is always just snarky remarks that almost always are totally wrong, and clearly demonstrate that they don't know what they are talking about.
Even if you never, ever use the Journal tools or access the Journal log files, systemd and Journal will enhance the Syslog files considerably, by enabling log info early in the boot process, and tagging and aggregate the logfiles.
IMHO, systemd and Journal is the best new tools for the Linux SA made in the past decade.
I really recommend reading this list of systemd myths:
They placed the AP's so that the heat they generated wouldn't affect the garden cress. Room temperature was computer monitored and regulated, the humidity was regulated, and they photographed the batches to document that no drying up or rot was present. They mixed the seed batches, randomized the seed selection etc etc.
The experimental setup and their elimination of errors and bias is considered to of very high quality, which is why they won a junior science prize. Their actual result meant nothing in that regard.
The first experiment was with idle AP's only broadcasting ESSID. The second experiment added some Linux laptops that ping-flooded to generate lots of network activity. The second experiment showed a clear increase in plant "damage"/lack of development.
The flame baiting, lame summery tries to make it looks like some evil diplomat tries to censor some facebook pages. But as the TFA says, this is about an imposter who has assumed a diplomats name on a fake facebook account and now post fake posts.
These two distros are very similar, with a few key differences but in both you can choose how stable or not stable you would like. If you want stable, you can have stable. If you need bleeding edge, you can have bleeding edge.
Granted its not "automatic updates" but I don't like the idea of my server doing updates like that without me initiating them.
The point is that RDO isn't a new distro, or a specific RH flavour of OpenStack, but just plain vanilla OpenStack builds, nicely packed in RPM's and with a "yum" repository. So RH based distros like Fedora 18, CentOS, Scientific Linux can install and maintain it, just by enabling the RDO yum repo.
I haven't seen a prototype, but a really hot technology that would fit perfectly with a watch device is two factor authentication (2FA) with one time passwords (OTP), combined with NFC, and probably some biometric stuff too. Use it to lock or unlock your phone, tablet, pc, to encrypt your devices, and really good password management and internet authentication and secure connections. Could be used to boost credit card and on-line banking security significantly. It wouldn't matter any more if a hacker stole your password from either your pc or from a web service break in; they can't abuse the password without the iWatch too.
Could be integrated with your car or house lock system too, or your house lighting system.
Since it could work as a broadcasting tracking device, high end boutiques could use it to dispatch grovelling salespersons directly at the iWatch wearer when they entered the premises:-)
I really don't have the technical knowledge to praise or damn the idea, but as I understand it, there are some clever moves in this;
It appears that they rip out enough of Android that they can use the Android graphic drivers for Mir, so that every device with android drivers delivers "free" drivers for Mir too. That would give them a huge advantage in the Smartphone and Tablet arena.
QtMir, QtUbuntu, Qt/QML; it looks like Ubuntu dumps Gnome/GTK in favour of Qt5 for core OS (GUI) development. As I see it they will clone KDE/Qt, substituting the KDE parts with QtUbuntu.
I'm also hoping to start using a Yubikey for password authentication, just waiting for my hardware token to arrive in the mail.
"Yubikey" looks very interesting. I have been thinking about two-factor and OTP hardware to increase my security, but I wasn't aware of actual implementations that worked for Linux.
"Come on, who doesn't want individual audio level settings for each program?"
Me. WTF do I need that for? My system sounds just fine, always has although audio is rarely used. Mostly just in connection with multimedia apps, and the login screen.
The point is that PA allows unobtrusive audio clues, like a gentle "ding ding" 10 minutes before an appointment, even though you are listening to fairly loud music. I like the fact the sound levels in VLC and Amarok is different from the rest of the system. Before PA there wasn't a functional sound daemon, so everybody just turned off any sound notifications and manually set the sound level to zero to avoid a sudden blast of noise when accidental starting a web commercial, or when "System Bell" gave a extremely loud warning "DING!" just because you had been listening to load music earlier that day.
Not talking about the problems with running sound i Dosbox, or using two apps with sound at the same time, bluetooth sound, etc. PA solved all those problems, it just works and makes life easier for developers, distro makers and end users, which is the reason why all major Linux distributions have converted to it. People trash talk PA, but it just that, trash talk, without technical argumentation, without any alternative to the many features that PA gives, and without regard to the fact that PA works well in the real world.
That's it.
ALSA did everything I needed for years, and ESD/OSS before that. As a user I really don't give a rat's ass how the code looks behind it all, as long as it works, which it did.
As far as SysVinit, same idea - it worked, and worked very well for decades. I still have no use for fast booting since I rarely if ever reboot. And I fail to see what other use there is for tinkering with something that worked just fine - I liked the old scripts since they were very self-documenting and easily modifiable.
So, no. Keep it.
SystemD goes way, way beyond the wish of faster booting. It really is a Sysadmins dream come true when it comes to controlling the many services (not just daemons) that runs on modern Linux systems. "systemctl" is just a natural, UNIX like way of controlling all these services from the command line or in scripting. "init/Sys V" was perhaps a fitting system for the needs of Unix boxes in the 1980's, but modern day servers and desktop systems have other needs, and init scripts are complicated, messy and fragile to edit. SystemD is just so coherent and natural to use, and allows far superior ways of maintaining, configuring, and monitoring systems.
I think your main problem is, that make your own way of using your system, a baseline for everybody else. You may not use sound very much, but many people actually do, you probably don't use bluetooth sound on your system, but many Linux devices, like smartphones do, you may not have the need to tweak init scripts, or administrating or monitoring services on a server, but other people do.
pulseaudio sucks donkey balls. It plain works unless it doesn't, in which case you're fucked. Fortunately plain ALSA works as good as ever and since I first encountered pulseaudio I've kept it off my systems and I haven't had any problems.
I was an early adopter of PulseAudio since I used Fedora Core. Yes I had problems in the beginning, but only because I used my uncommon internal audio chip. When I used an old, but common and well supported SB 16 card, my problems went away. Really, if you still have problems with PulseAudio, it is because your distro or the audio chip drivers sucks.
Not only does PulseAudio works, it provides features and benefits that ALSA/ OSS/ESD/ArtsD doesn't have. PulseAudio is an elegant solution to the many problems Linux used to have with its audio system. Come on, who doesn't want individual audio level settings for each program?
Slashdot Mirror
Neil deGrasse Tyson says only the government can do Space.
That is simply a lie. In fact he found it scandalous that the private commercial space program was delayed so many years. RTFA.
If only this was because Tepco was wilfully concealing the radiation level in order to save money, but this is likely to be caused by symptomatic incompetence on so many levels in Tepco. One wonders what stupendous errors and failures Tepco will provide in the future.
Instead of progressing, the situation at the Fukushima plant seems get worse day for day; the water tanks are corroding and leaking, the local radiation levels seems to break new records every month, the ground beneath reactor 4 is apparently unstable, no one have a clear picture of what exactly is going on inside the reactor buildings because of the massive radiation, and up until now, only "band aid" work and cleaning have been done; the most difficult and dangerous job of removing the spent fuel rods have barely begun, and is likely to take many years.
And every day is a disaster potentially waiting to happen; if the cooling is lost for whatever reason, the fuel rods may start a spontaneous radiological fire, releasing 3-10 times the radiation as the original 2011 disaster:
http://www.bellona.org/filearchive/fil_Holophi-Special-Report-on-Fukushima-SFP-4-r.pdf
Oh, and the same report cites a scientific paper on how new magnitude 7 earthquakes are expected in the area (Tong et al, 2012).
One hopes that Japan are lucky with the wind direction again if the worst should happen, the human and economic consequences of massive radiation cloud spreading over the Japanese inland instead of the sea, are barely comprehensible.
That makes me wonder, if a country has no military, is it illegal to attack that country since it is completely civilian?
No, if you by "attack" means "occupy". However, excessive use of force in occupying a country without any military forces would be illegal.
Other things besides excessive use of force could render such an occupation illegal, if it eg. was an unprovoked occupation. (casus belli, aggressive warfare and all that).
An example of an legal occupation of a country without military forces, could be the British occupation of Iceland in 1940.
It is in fact difficult to imagine any war, where the use of chemical weapons wouldn't cause disproportional losses among civilians
Why imagine it when it actually existed? It was WW1. For that matter, most uses of chemical weapons in Iran-Iraq war were on the battlefield against enemy soldiers, as well.
Yes, using chemical weapons in a middle of a populated city guarantees civilian casualties. But then so do sufficiently powerful bombs, which didn't stop NATO from using them in Belgrade in 1998.
I am well aware of WWI. In fact, the use of gas during WWI caused disproportional many civilian deaths compared to the minor military death count. The soldiers quickly got gas masks, had extensive warning systems etc, so gas attacks quickly became ineffective in killing soldiers. The civilians didn't protection and warning systems, and as a consequence often died an large numbers if the wind blew over their village.
So WWI completely support what I wrote.
I am not an expert on the Iran-Irak war, but I can assure you there was many civilian casualties from chemical weapons, either because they ware targeted directly, or as collateral damage.
Eg. the Iraqis used mustard gas variations, which doesn't killed immediately (3-5% mortality), but cripples people often for the rest of their reduced life.
People often have a cartoonish perceptions of battlefields, especially WWI, and often have loud opinions about the conduct of the war without ever reading a single scholarly work about it.
Your perception that the war was fought far away from civilians are dead wrong, almost 2 millions civilians died in WWI as a direct result of military action.
Second: Bombs that unleash pieces of metal are usually used for specific targets not large populations.
Dresden? Tokyo?
Neither the British nor the US bomber command targeted civilians. The bombing of Dresden ( a major military target, besides being an important railway centre) was part of the official "de-housing" policy, where major cities was bombed in an effort to cripple the German war production; not only would such bombings smash infrastructure like railways depots, they would also hit the many factories and small workshops in the city centres, and finally, it was believed, that by destroying the houses in the cities, they would render them useless as production centres.
One could of course argue, that the difference was very small. But anyhow, the German civilian casualties were small compared to German military losses, showing that the allies didn't wage war against civilians. The German civilian loses from air raids are estimated to be around 400.000 (including allied POWs, foreign labourers, paid or slaves etc.). The combined US/UK loses of airmen where around 150.000. Not an impressive kill ratio if the allied had intended a bomber war against civilians.
It is indeed a very complex issue to which there is no easy one line answers. But there is a sort of logic behind why some weapon systems are banned, and others not, or how even legal weapons can be used in an illegal way.
It is not about some weapons being good or bad, or even the amount of suffering they cause at the individuals affected by them. It is all about keeping military actions under control causing the least amount of suffering among soldiers and civilians in relation to the objectives of the military action. A main reason behind this is the axiom, that war directly targeting civilians is illegal.
The problems with weapons of mass destruction, like chemical weapons, are that their effects can't be controlled; they go where the wind blow. Furthermore, they tend to affect civilians much more than soldiers who often are protected against NBC attacks. All in all, using chemical weapons in a city is effectively targeting civilians, not soldiers.
It is in fact difficult to imagine any war, where the use of chemical weapons wouldn't cause disproportional losses among civilians, so returning to the axiom that wars and military actions directly targeting civilians are illegal, it has some kind of logic, that chemical weapons are banned, while targeted weapons like bombs are not.
I think a lot of the traditional thinking about servers are changing: VM's, OS-containers, cloud computing means, that the traditional big iron, unchanging OS with hand crafted config files, is receding. Instead all the interesting stuff will happen in mass deployed auto configured VM's, or OS-containers (OpenVZ, LXC etc). There will be VPS's (Virtual Private Servers, served from the cloud), etc. etc.
With services doing live migrations across data centers, and services being configured and executed on a demand only basis, and everything interesting in fleeting VM's and containers, they need for long term feature stable servers may recede;
So while Fedora may not be everyone's choice for a bare metal VM and container server, it may very well be exactly what you want to put inside those VM's and containers. This is why it is important to rethink the Fedora distro. As it is now, its base install very much reflect old style UNIX thinking (nothing wrong with UNIX style, but such servers are not the whole story), that means the base install pulls in stuff like "ed", "tar", "file" etc. While they may nice little standard programs, they may not make sense in a custom VPS.
This Wikipedia article (footnote 39) claims that a controlled recording in Mongolia showed the connection between sound and meteor falls:
http://en.wikipedia.org/wiki/Meteoroid#cite_note-BBC-321596-39
There are several suggestions what causes the the simultaneous sound, but AFAIK, no one has really made a solid case with measurements to back up their theory.
Oh the 2001 Leonid shower was the best meteor shower I have ever seen. Fireballs streaking across everywhere. An many of them made that crackling/hissing sound when they flew across the sky. It is still unknown how the meteors make that sound and how the noise is able to propagate faster than the speed of sound. (You shouldn't be able to have simultaneous sound with a meteor, since they are +40 km away.). But the crackling sound was widely reported with the 2001 Leonid shower, and AFAIK, scientist have at least actually recorded "noisy" meteors now.
Light pollution is just a sad phenomenon. I have to use a binocular just to see stellar constellations that are easily visible to the naked eye in just semi dark places. I haven't seen the milky way in over a decade.
is the only part of the Calligra Suite I have really tried out (version 2.6.4). It lacks some features necessary for me, but it is a nice lightweight word processor. Its best feature is its tabbed & indexed sidebar. Just moving icon toolbars to the side doesn't work. It seems so logical to use some of that wide screen real estate for toolbars, but in reality it is hard to make sidebars work.
But Calligra Word has got it right:
Text instead of icons.
Tabbed & indexed to maximize the information, but without losing spatial memory of where functions are. (The main thing I hate about Microsofts "Ribbon").
The Calligra Word "Dockers" is also a very nice concept: they are basically information and toolbar tiles that defaults to the right side. They can either be compressed when tiled together, be tabbed behind each other, or float freely
Looking at the screenshoot of the new 2.7 version, they seem to have improved the toolboxes and their layout even further
Another thing Calligra does very well, is integration with the other components. The Calligra Word has superb drawing and figure making and manipulation abilities, while feeling really fast and lightweight at the same time, no long waits or disc trashing while the drawing component is started etc.
It really shines when it comes to making fast one-off DTP/presentation stuff like combining text, figures and pictures, and connecting them with lines.
Of course, old DSL routers and similar. I was thinking too much in traditional network wiring. I can see the reasoning now for speccing 10Mbit as a mandatory minimum, and it probably more or less free to implement if you are going for a 100/1000Mbit nic anyway, so why not be compatible with even corner cases.
I must say, I think EOMA-68 looks very intriguing, it would be exceedingly cool if more devices was made that way.
I mean, does a tablet with a removable CPU card make any sense whatsoever?
Perhaps not for the average consumer, but for the tinkerer it sounds fun; use a A10 ARM CPU card for long battery times (e-reader etc), or a AMD T40E 64-bit x86 dual-core CPU with on-board Radeon 3D graphics (r600) for maximum performance (serving video, ethernet sniffer, games).
A I understand it, the EOMA-68 CPU card standard means that the same board potentially can be used in different devices, NAS, tablet, netbook, PVR etc. So it can potentially cut costs when developing a new device, since a lot of the essential stuff is already designed and tested.
It is perhaps a pipe dream, but I would like to live in a world with more FOSS hardware for excellent Linux support. I like the idea of exchangeable hardware done by standard open interfaces.
I would certainly like a tablet with full Linux support, especially with KDE Plasma. Never heard of the "EOMA-68" standard before, but it looks intriguing . Not sure why they specced 10Mbit ethernet support as mandatory minimum for the CPU card. 10Mbit networks must be very rare these days, and the cheap misers who still operates them are unlikely to purchase a tablet. Am I missing something?
Anyway I like the CPU card concept, but I hope the tablet will have GPS, and accelerometer, gyroscope, (digital) compass, or else it has to be cheap.
And how do I do that when, for example, configuring a non-running system from a different system? Like, for instance, setting up embedded systems?
You don't _need_ the *ctl tools to configure a systemd system. Just use "ed -G" (or "vi" if you need some hand holding wysiwyg GUI) to edit the text configuration files. This is no different from sysvinit.
systemd and journald support live remote logging and what not, and if they doesn't all ready support reading of offline log files, they surely will. (not something I have looked at, but perhaps "systemd-journal-remote" is what you need).
The reliance on *ctl apps that have to actually run on the system is a big step back, towards Windows and how you can't really do much about the registry or event logs without a running and compatible Windows system, and for many things THE system it runs on.
This is the direction systemd/journald is taking us, and we've seen this before, with AIX. It didn't impress us then, and it doesn't now.
Those who don't know (Unix) history are doomed to repeat it.
Having to rely on systemctl is no different than to rely on eg. Bash, vi and all the nice GNU tools, without those, not much can be done.
I see no real world problem in either using the tools on the running system by using eg. ssh, or having a systemd compatible system to analyse log files on a remote system (either offline or live remote logging). In fact, I don't think this is any different from using sysvinit/rsyslog today, except that systemd offers better tools for analysing problems and much better security etc.
They didn't help me when systemd crashed and took with it the entire system. It's built as a card house, with assumptions that things don't go pear shaped, or if they do, you have time to wade through hundreds of configurations in search of the proverbial needle in a haystack.
I don't LIKE systems where you put all your eggs in one basket, and for good reason.
This is no different from a failed init that causes a kernel panic. The difference is that systemd now is thoroughly tested on *thousand of machines and keeps improving, so using it to control services will minimize all the dangers that comes from hand editing complicated, often undocumented init scripts.
systemd has superior debugging facilities and is well documented. You can actually systematically analyse what a certain run-level (called target) requires, or tell systemd to spawn a shell if it crashes. It is so much better when it comes to tracking down service/daemon troubles than static scripts.
Sure, there is something to learn about systemd before mastering it, and many people seems to loathe reading about new technology, or just doesn't have much time on their hands to learn new stuff. But neither is a systemd problem, and learning new technology and new ways of doing things, comes with the territory as SA.
Check out all the wonderful stuff one can do with systemd, journald, and all the *ctl tools; completely consistent control and behaviour across every Linux system that uses systemd. No need to learn and relearn dozens of small system peculiarities across distributions for controlling services, working with log-files, getting system info, etc. etc.
systemd is the future because it is such a good idea that most major distributions are switching to it. I will recommend all Linux SA's to put their real or imagined reservations against systemd aside, and start boning up on the subject
There is a lot to learn, not because systemd is complicated, but because it can do so many things, like resource limiting, mounting etc.
Here is a link that compares sysvinit, Upstart and systemd
http://0pointer.de/blog/projects/why.html
Come on, "On-demand socket activation for per-connection service instances" for virtual servers, how cool is that!
And what do you do when something goes wrong? Or you need access from a different arbitrary system?
That sort of questions is exactly why you should read the linked pages. So calm your fuming hate against Poettering and start reading.
I guess your very vague question is something about accessing Journal log files, something you probably think can be problematic since they are binary, right? No worries mate. Syslog is a first class Journal client, you can read all the usual text file stuff in /var/log/* if for some reason journalctl doesn't work, but everything else does. Journal send all messages to syslog, including early boot stuff that syslog couldn't log before.
It is just that when journalctl (and all the other cool *ctl tools) works, it is faster, easier and more secure than the usual chaotic syslog logging. So what is wrong with displaying not only an error message, but also the exact link where the error message is explained and documented? "journalctl -f" instead of "cat /var/log/messages | tail" ?
Cryptographic secure logging? That you have an actual guarantee that a message is written by the daemon it claims?
"journalctl", "systemctl" and all the other *ctl tools like localectl, hostnamectl and loginctl, are just wonderful and powerful tools, that promises some kind of consistency when it comes to Linux logging and system information gathering etc.
I think its just cranky old sysadmins that don't like systemd. Its actually quite good and offers several benefits over the old sysvinit.
It's the cranky old sysadmins who keep the servers and internet running. What they say is often important. When someone tries to re-invent Windows Services, AIX smit and Windows Event log, they may grump, but they do so with the experience saying that it wasn't a good idea the last time either.
The problem is that many aren't "cranky old SA's" but just uninformed old gits that refuses to even read up on new technology and flat out denies that there any problems whatsoever with Linux logfiles, and the way Linux handles services (init etc).
Whenever I see systemd or Journal hate here on Slashdot, it is always just snarky remarks that almost always are totally wrong, and clearly demonstrate that they don't know what they are talking about.
Even if you never, ever use the Journal tools or access the Journal log files, systemd and Journal will enhance the Syslog files considerably, by enabling log info early in the boot process, and tagging and aggregate the logfiles.
IMHO, systemd and Journal is the best new tools for the Linux SA made in the past decade.
I really recommend reading this list of systemd myths:
http://0pointer.de/blog/projects/the-biggest-myths.html
And Lennart's "systemd for Administrators". Here is a link to the first part of twenty instalments:
http://0pointer.de/blog/projects/systemd-for-admins-1.html
Very good stuff. A must read for any Linux SA, whether they think they dislike systemd or not.
They placed the AP's so that the heat they generated wouldn't affect the garden cress. Room temperature was computer monitored and regulated, the humidity was regulated, and they photographed the batches to document that no drying up or rot was present. They mixed the seed batches, randomized the seed selection etc etc.
The experimental setup and their elimination of errors and bias is considered to of very high quality, which is why they won a junior science prize. Their actual result meant nothing in that regard.
The first experiment was with idle AP's only broadcasting ESSID. The second experiment added some Linux laptops that ping-flooded to generate lots of network activity. The second experiment showed a clear increase in plant "damage" /lack of development.
The flame baiting, lame summery tries to make it looks like some evil diplomat tries to censor some facebook pages. But as the TFA says, this is about an imposter who has assumed a diplomats name on a fake facebook account and now post fake posts.
Red Hat is doing something no other distro vendor has done
... Gentoo? And Daniel Robbins' Funtoo project?
These two distros are very similar, with a few key differences but in both you can choose how stable or not stable you would like. If you want stable, you can have stable. If you need bleeding edge, you can have bleeding edge.
Granted its not "automatic updates" but I don't like the idea of my server doing updates like that without me initiating them.
The point is that RDO isn't a new distro, or a specific RH flavour of OpenStack, but just plain vanilla OpenStack builds, nicely packed in RPM's and with a "yum" repository. So RH based distros like Fedora 18, CentOS, Scientific Linux can install and maintain it, just by enabling the RDO yum repo.
There is a quickstart guide and lots of documentation here:
http://openstack.redhat.com/Quickstart
All in all, this makes it really easy to test and play around with OpenStack.
I haven't seen a prototype, but a really hot technology that would fit perfectly with a watch device is two factor authentication (2FA) with one time passwords (OTP), combined with NFC, and probably some biometric stuff too.
Use it to lock or unlock your phone, tablet, pc, to encrypt your devices, and really good password management and internet authentication and secure connections. Could be used to boost credit card and on-line banking security significantly. It wouldn't matter any more if a hacker stole your password from either your pc or from a web service break in; they can't abuse the password without the iWatch too.
Look at Ubikey for a 2FA, OTP, NFC usb device:
http://www.yubico.com/products/yubikey-hardware/yubikey/
Could be integrated with your car or house lock system too, or your house lighting system.
Since it could work as a broadcasting tracking device, high end boutiques could use it to dispatch grovelling salespersons directly at the iWatch wearer when they entered the premises:-)
I really don't have the technical knowledge to praise or damn the idea, but as I understand it, there are some clever moves in this;
It appears that they rip out enough of Android that they can use the Android graphic drivers for Mir, so that every device with android drivers delivers "free" drivers for Mir too. That would give them a huge advantage in the Smartphone and Tablet arena.
QtMir, QtUbuntu, Qt/QML; it looks like Ubuntu dumps Gnome/GTK in favour of Qt5 for core OS (GUI) development. As I see it they will clone KDE/Qt, substituting the KDE parts with QtUbuntu.
Their time line seems very optimistic though.
Denying root access
I'm also hoping to start using a Yubikey for password authentication, just waiting for my hardware token to arrive in the mail.
"Yubikey" looks very interesting. I have been thinking about two-factor and OTP hardware to increase my security, but I wasn't aware of actual implementations that worked for Linux.
"Come on, who doesn't want individual audio level settings for each program?"
Me. WTF do I need that for? My system sounds just fine, always has although audio is rarely used. Mostly just in connection with multimedia apps, and the login screen.
The point is that PA allows unobtrusive audio clues, like a gentle "ding ding" 10 minutes before an appointment, even though you are listening to fairly loud music. I like the fact the sound levels in VLC and Amarok is different from the rest of the system.
Before PA there wasn't a functional sound daemon, so everybody just turned off any sound notifications and manually set the sound level to zero to avoid a sudden blast of noise when accidental starting a web commercial, or when "System Bell" gave a extremely loud warning "DING!" just because you had been listening to load music earlier that day.
Not talking about the problems with running sound i Dosbox, or using two apps with sound at the same time, bluetooth sound, etc. PA solved all those problems, it just works and makes life easier for developers, distro makers and end users, which is the reason why all major Linux distributions have converted to it.
People trash talk PA, but it just that, trash talk, without technical argumentation, without any alternative to the many features that PA gives, and without regard to the fact that PA works well in the real world.
That's it.
ALSA did everything I needed for years, and ESD/OSS before that. As a user I really don't give a rat's ass how the code looks behind it all, as long as it works, which it did.
As far as SysVinit, same idea - it worked, and worked very well for decades. I still have no use for fast booting since I rarely if ever reboot. And I fail to see what other use there is for tinkering with something that worked just fine - I liked the old scripts since they were very self-documenting and easily modifiable.
So, no. Keep it.
SystemD goes way, way beyond the wish of faster booting. It really is a Sysadmins dream come true when it comes to controlling the many services (not just daemons) that runs on modern Linux systems. "systemctl" is just a natural, UNIX like way of controlling all these services from the command line or in scripting. "init/Sys V" was perhaps a fitting system for the needs of Unix boxes in the 1980's, but modern day servers and desktop systems have other needs, and init scripts are complicated, messy and fragile to edit. SystemD is just so coherent and natural to use, and allows far superior ways of maintaining, configuring, and monitoring systems.
I think your main problem is, that make your own way of using your system, a baseline for everybody else. You may not use sound very much, but many people actually do, you probably don't use bluetooth sound on your system, but many Linux devices, like smartphones do, you may not have the need to tweak init scripts, or administrating or monitoring services on a server, but other people do.
pulseaudio sucks donkey balls. It plain works unless it doesn't, in which case you're fucked. Fortunately plain ALSA works as good as ever and since I first encountered pulseaudio I've kept it off my systems and I haven't had any problems.
I was an early adopter of PulseAudio since I used Fedora Core. Yes I had problems in the beginning, but only because I used my uncommon internal audio chip. When I used an old, but common and well supported SB 16 card, my problems went away. Really, if you still have problems with PulseAudio, it is because your distro or the audio chip drivers sucks.
Not only does PulseAudio works, it provides features and benefits that ALSA/ OSS /ESD /ArtsD doesn't have. PulseAudio is an elegant solution to the many problems Linux used to have with its audio system. Come on, who doesn't want individual audio level settings for each program?