EDF has been losing money not on generation but on building projects that had bad management practices. Generation is highly profitable, as most of the plants long paid for themselves and are generating pure profit at this point.
Some electricity generation is profitable because they have a de facto monopoly and can sell to consumers at artificially high prices. If they had to compete on market prices most nuclear reactors would sell electricity at a loss.
That is exactly the reason there isn't a free market working in France on electricity; it would bankrupt the nuclear industry.
The nuclear sector in France have state guaranteed profits. Even the new electricity tarif scheme with some market elements in it, ensures that they get guaranteed minimum price for the generated electricity, the difference being paid by French tax payers and consumers.
Regarding EDF's failure to build new reactors on time on budget; well, the entire nuclear industry suffers from this, including the ones in China and Russia. It basically means that new reactors will rely even more on state subsidies and regulation to operate.
French electricity prices and subsidization is highly complex, including extra subsidization for families below a certain income level. And now it is changing yet again. The new change will introduce a element of market pricing. This is why Moody's and Standard and Poor have been downgrading EDF stock:
Be wary of using simple charts of electricity prices across EU: the one you quoted includes various taxes too, so it doesn't reflect _production prices_ at all, only what the consumers pays, probably averaged heavily too, since the price structures are varying like different day and night prices etc. Some countries have high electricity taxes making their consumer prices high, even though the production price may be low.
If you look at production prices, nuclear power can't compete. This is also the reason why no one really builds new nuclear power plants in the US, since local laws often forbid passing above market prices to consumers.
There may be good reasons to have nuclear power plants, like the ability to make nuclear weapons, reduce CO2, etc., but they can't compete on production prices, so consumers and tax payers will have to foot the bill.
The electricity prices are still low in France thanks to government regulation, but they are scheduled to rise significantly over the next years. The prices have been artificially held low so that the French nuclear energy sector (EDF etc.) have been bleeding money and raking up debt like there is no tomorrow, while taxpayers have footed the rest of the bill.
So the French nuclear sector are also effectively subsidizing their nuclear power by making French tax payers pay the bill. Yes, they still have low electricity prices, but that is only because they pay more taxes on their wages to keep the electricity prices artificially low. This can't go on.
The move to reduce dependency on nuclear power is made because France is moving away from subsidized prices, so the consumers will pay more in line with what it actually cost to produce the energy directly instead of hiding the costs in higher taxes or forcing the utility companies to sell at too low prices.
The problem for the nuclear sector is that it is unable to compete on market prices. So if you want a more competitive and less regulated energy market in France, you have to reduce the reliance on nuclear power.
The main reason is cost. Nuclear power can't compete on price with neither fossil fuels nor renewable energy like solar or wind. So basically every french nuclear power station is a hole into which the consumers are shoveling money into.
You simply can't build or operate a nuclear reactor power station anywhere in the world that can compete on market prices.
For France, the ever more connected EU electricity grid means an ever increasing pressure on the energy sector to be able to compete on EU electricity prices. The long term prospects for nuclear energy to ever be able to compete on prices looks bleak, even if fossil fuel prices rises significantly.
In the meantime much more nimble energy technologies like solar and wind continues to make significant progress in cost and efficiency. And unlike nuclear power plants, they can quickly deploy the newest technology in the field.
So it really makes a lot of sense for France to lower its reliance on nuclear power and start to invest more in renewable energy resources.
All joking aside, historically that's exactly what happened! The crack of the Enigma in particular and German/Axis crypto in general, was kept very secret just to foist broken encryption onto the world.
The Enigma with Steckerbrett used with good operational procedures was actually practically unbreakable even in the decades after the war. While some aspects of the Enigma designed "leaked" info about its configuration, it was a sound design, and AFAIK, practically identically to what the allied used. That the allies could decrypt Enigma messages was almost entirely caused by bad German operational procedures and the capture of code books. Even today it is a massive computational effort to break historical Enigma messages.
So the countries receiving Enigmas could have had practically unbreakable crypto with the right operational procedures.
I read recently that the Allies made a policy of not telling about the decryption until long after the war, apparently so everyone would think we won by valor rather than by cheating. But what's (perversely) funny is that the UK rounded up as many machines as they could and "donated" them to third- world countries so that they, too, could enjoy the benefits of strong encryption.
No. The reason why the allies kept extremely mum about cracking the enigma was simply because they had learned the hard way that this was the right thing to do.
It goes back to the first world war when the British "Room 40" cracked German naval codes. The German navy knew nothing of this until W. Churchill published a history of the war where he "spilled the beans" about it. The German Navy and army where shocked when they learned how their crypto had been compromised and decided to strengthen their crypto to previously unheard levels. That is the reason why they bought and deployed the Enigma machines.
The Enigma was practically unbreakable at the time if used correctly, so it was by a thin margin that the Allies where able to decrypt Enigma messages. So they felt it was absolutely vital reveal nothing about their successes after the war, so future potential enemies didn't improved their crypto and crypto-procedures even more.
The conservatives are just getting their panties in a bunch because they can no longer demand "moral" state backed censorship of the net.
Hyperbolic claims are about SPAM not being allowed to be blocked, are just sad political attempts to institute state sponsored censorship through the backdoor.
Looking at V. Ford's homepage just says she unsurprisingly supports companies right to unlimited spamming of customers, something that the new rules also forbid.
Of course SPAM filtering is allowed under the new rules.
Maybe there is an EU member state where SPAM/UCE is legal, but in all EU countries I know of, it is illegal and therefore can be blocked. Not only is the act of spamming illegal, but since they almost always use criminal methods like mass hacking, that fact too is reason for blocking all such SPAM.
ISP default content filtering or state mandated content filtering of legal stuff will be prohibited. So the UK state dictated "opt out" filtering will be illegal, while Symantec's etc. individually enabled and user controlled content filtering will be allowed.
You sound like you have been badly informed by some punter site.
At first glance the new net neutrality rules looks very good. The "non-blocking" rules seems to make default and opt-out ISP porn-filtering illegal. If a site/service isn't illegal in one way or another, the ISP must not block it.
Sure, the ISP can offer various content filters as an opt in solution, leaving any such decisions to the individual where such decisions belongs, but the ISP can't "opt in" everybody, nor can any member state make any such filters mandatory.
From a free speech perspective that is a huge win on top of the network traffic net-neutrality rules.
I can't see anywhere if these rules are only binding within the EU, or if it is legal to block/throttle non-illegal sites and traffic from sites outside the EU. Does anybody know?
You mean one developer, who's known for throwing shit together in a crufty way, managed to convince three people at the "PNELV" by either boring them shitless or throwing a tantrum.
No, I mean many many kernel developers, including the guy who maintain all long term stable Linux kernels for the Linux-foundation. Basically the second guy besides Linus Torvalds that the LF employ.
I have seen zero kernel developers backing any other Linux init-system. In fact, the Linux developers seems to actually flee from the rather toxic systemd-hater camp that you and your juvenile behaviour are stellar examples of.
Seriously, who would ever work in a project with a poisonous guy like you?
You are cherry-picking the one thing that isn't logged by most syslog daemons by default,, in a disingenious attempt to show that syslog is "worse", even though it is off by default because it is of little use. If we cared AT ALL to have the "log level" information, it would be logged.
I chose the example because it has proven really useful to me. The example will quickly show any serious error that may have cause a system to fail. Being able to filter out all boot-sessions that aren't relevant is really useful. Being able to see all serious errors on a system at a glance is really useful too. Being able to easily combine such queries into one is pure gold.
But there is so much more that syslog doesn't log. This brings on another fundamental problem with text logs; they are hard to parse for machines due to their lack of structures, and they become hard to parse for humans too if they contain too much information.
Monotonic and micro-precision timestamps are great, but they foul up the readability of syslog textfiles simply because they make the lines longer. So basically syslog can't put the same amount of logging info in the log files, not for direct technical reasons, but because the log file format is inadequate.
The systemd journal on the other hand, can easily be extended with ever more fields as needs arise. And it can do so without breaking userland!
Because another problem with the unstructured syslog text logs are that they have no programmatic API or even "labels" for each part of a logging entry. That means the very structure of the log entries has become a sort of API, so changing that structure by adding more information, and thousands of userland log-watcher scripts that rely on "cut" simply breaks down.
The discussions of the many limitations of syslog,
Fine. Then solve the problem where it should be solved, and add this to/etc/syslog. You systemd apparatchik like editing non-script-based config files, right?
Many of the problems can't be solved by adding features to syslog. If you want "metal-to-metal" logging you just got to design something like journald for so many technical reasons, including that the Linux kernel only accept one owner of/dev/log.
But as said, the most fundamental problems are the total lack of coordination between stuff in Linux. It is almost impossible to improve some things because of that. The Rsyslog team have fought valiantly over the years, but the sheer lethargy and no formal coordination means changes are hard to impossible.
The systemd team solved this problem in the most elegant way possible; they made a new logger that were 100% backwards compatible with syslog, but at the same time introduced radical new features. The end-users could user whatever option that suited them best, and userland didn't have to change a line of code, while still benefiting from the new features. This way all the systemd Linux distros and userland programs can slowly migrate to using the new journald logging API. No "flag day" problems!
# probably already in the config source src { system(); internal(); }
# link the filter to a destination log { source(src); filter(f_err_only); destination(err_only_log); };
Now you can read those messages only using "less". You DID know that syslog has very flexible log routing and filtering capabilities, right?
I think the above examples greatly illustrate several problems with syslog text-files. But first; despite spanning several lines, it isn't even remotely close to what "journalctl -b -
Systemd will fail in the long run. Systemd lovers are just like the windows fanatics of yester year. My company has thousands of Linux systems guess what none of them are moving to a distro the uses systemd and never will. We will still keep making money. And will have a freedom of choice. So go suck it systems lovers.
Why should I care that you don't use a systemd distro? If you are making money on Linux, great. If you are using eg. Slackware to do so, hey, that is great too. I respect mr. Volkerding and his way of making a distro.
I like freedom of choice and I think systemd provides exactly that. Even if you don't like it, you benefit from the fact that there now are several udev-implementations (before there was just udev and the limited mdev) and several ConsoleKit/systemd-logind implementations (before systemd there was only CK).
But apparently the freedom of choice doesn't include the right to choose systemd.
That is a major problem with the behaviour of the anti-systemd camp; they won't accept that highly skilled Linux developers (including Kernel developers) and experienced distro and system maintainers, thinks that systemd is superior to whatever else out there, and therefore chooses to build their distro around it.
This lack of accepting other peoples freedom of choice is why you are trolling a Debian thread, even though you don't use the distro and claim you never will.
So think about what you are actually doing before saying "freedom of choice" again.
How does journalctl fare in terms of having a trigger set up to automatically do things with logs when they're inserted?
The classic problem was speed. A DB was fine for storing and analysing, but could be severe bottleneck for log sinks. It isn't so great for local system logging either since DB's tend to appear rather late in the boot sequence.
With journald you can have system logging before the rootfs is even mounted, and since both systemd and journald can pivot back to initramfs after the rootfs has been unmounted, you can potentially have logging after that.
These days it seems that people are using a mixture of DB's and heavily data massaged text logs (JSON etc) combined with a special index (Splunk etc).
There will never a single log storage solution for all, since the tools chosen will reflect the problems trying to be solved. For some it is auditing that is important, for others it is analysing website usage.
But since systemds journal is structured and field based, it is very easy to convert its log entries to standard JSON etc that consistently fits other storage means. A huge improvement over the many different syslog implementations.
Re: triggers. You don't use "journalctl" for that, but the API/libraries/language bindings. systemd provides a really good and well documented framework for making triggers, but don't provide them as such. You can have instantly triggered events on file systems that supports it. "man sd_journal_get_events" documents the C API: http://www.freedesktop.org/sof...
But there are also Ruby, Python, Go bindings etc. All in all I think systemd/journald is a major upgrade when it comes to log watchers; stable API, field based filtering, many language bindings, instant notifications etc.
Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex. (the line shows all log entries from the previous boot with the syslog severity level "error" and above, try that with grep!).
just playing around with "journalctl" for 10 minutes convinced me wholly.
So you've never tried using rsyslog to log to a database then?
Yes, so I know the many limitations of doing so. It is of course of interest to know that Rainer started the Rsyslog project exactly to overcome the many problems with the old syslog(3) interface, especially the problems with flat file text logs.
I have much respect for the Rsyslog developers work and it certainly weren't their fault they couldn't fix all the problems they set out to solve. So I am glad that Rsyslog now can read/write systemd journal files, meaning that it can be used as a log sink (at least for simpler cases) without regressing to using flat text log files.
Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex.
That statement alone shows the core problem with the systemd evangelists: you don' t want to learn generic tools, and instead want to use single-purpose, monolithic[1] apps.
"systemtctl" is a first class classic Linux/Unix tools that works together with all the standard Linux tools like sed, awk, grep, less, tee and what not.
It isn't interactive, it isn't chatty on success, can be piped etc, just like all the good ole GNU stuff. Sure, it can read binary text files like the journal, but so can "last" that is required to be Posix compliant (used to read the utmp/wtmp binary log files). And what about zgrep?
The systemd journal file format (basically an appended text file with non-standard delimeters+index) is fully documented and have excellent language bindings, making it trivial to make eg. Python scripts that read/writes directly into the journal. So it is trivial to make a "jgrep" or a "jless" that can directly read the journal if that is what you want.
The point is that "field" based logging is superior to the unstructured text dumps that syslog makes.
The point of what you call "faffing around with grep and regex" is that those tools are not difficult to use, and once you are familiar with the basics you now have a general tool you can apply to any unexpected situation.
Come on, claiming that regular expressions are easy is laughable. The old joke "I had problem. I decided to solve it with regex. Now I have two problems" is still true.
Not talking about that people should know the difference between regular and extended expressions, and that each and every tool uses its own maddening variation. Basically, if you don't use regular expressions as part of your everyday job, you are unable to use it without heavy man-page consulting for just the basic syntax.
I seriously doubt that any more than a tiny fraction of Linux users are able to whip out an even moderately complex regex. And that means the vast majority of Linux users can't filter their logs to any serious degree. It is so sad to see how people are literally trawling through the logs, reading them as a book in order to find problems. People are even using "vi" to do it, yikes. systemd's journal basically solves this problem for good for Linux newbies. It is fun to see how productive people can become with "journactl" after a 10 minute introduction.
For power users, the field based approach is immensely powerful too. If you remember how Rsyslog started a decade ago, it was exactly to overcome the many limitations of flat file text logs.
syslog severity level "error" and above
I have never even remotely needed to filter events by syslog(3)'s "level" bits - it's not a very reliable filter, as app can be inconsistent in what LOG_* flag they use.
It is a superb way to filter from both "that boot only" and "this severity only". One reason why you probably haven't tried it is because this is very hard to do using generic tools using flat file syslog text logs.
Filtering on the facility (source) or time is far more useful. If you find that particular command to be useful, then great - which would be a good example of how use-cases can vary a *lot* depending on what you're doing.
Even this is something journald does so much better than syslog; There is kernel guarantee that the source is always is always what it claims to be. Same with what program generated the log entry. It can even distinguish between two instances of the same program running simultaneously since each and every log entry is stamped with a unique id (and session ID, and machine ID so you can trail logs even if the hostname/IP changes or across multiple machines and OS containers).
Systemd is terribly unstable and rolls state back for trivial reasons. Those of us in charge of data centers see the issues, your laptop or home pc is not a viable model of reality.
What "state" are you talking about. This is Linux/Unix, not a transactional OS. systemd doesn't perform "roll backs". What trivial reason? Maybe that could explain what you are trying to say. It really sounds like you have no personal experience with systemd nor have read anything about it.
You are talking bullshit here, we've been testing systemd for 6 months and it is unstable, rolls the system back to start state for trivial reasons. Not to mention needing all kinds of shims for the parts that haven't even been written yet so it could "function" in a current system. What a bunch of badly designed over complicated garbage
There are no "shims" necessary to run systemd. On Debian there is "logind-shim", but no one should use that instead of the proper systemd-logind.
Comments like that, and your bizarre claim of " rolls the system back to start state" makes me suspect that you don't have actual personal understanding and experience of systemd management.
Sure, truly understanding systemd require some serious study, something way too many have neglected, thinking they could just wing it when time came. The payback for the time spend studying is that systemd also have some serious cool technology that is far superior to everything else in Linux/Unix land.
You are just talking bullshit here. I have been using systemd for +4 years now and it has been rock stable.
On a VM on your mom's MacBook that you take down to Starbuck's in a record bag slung over the crossbar of your fixie.
It is exactly because the systemd-hater camp apparently consist of technical illiterates like you, that they have lost each and every technical argument on all major distros. Ad hominem attacks and poisonous threats and trolling systemd threads are all you can do. Almost all volunteer developers have left the non-systemd camp because of its toxic atmosphere where attacking open source developers and users are as normal as breathing air.
Think about it; the anti-systemd faction couldn't even muster 5 Debian developers to sponsor a GR bill to overturn the technical committees decision of making systemd default init.
The negative, hate-driven anti-systemd campaign have resulted in that 100% of all commercial general Linux distros and most of the community driven distros are behind systemd and are supporting it. Talk about a losing campaign strategy.
No, it's not possible for systemd to have a bug. Our very own Peter H.S. told us that systemd is "rock stable". "Rock stable" software systems don't have bugs! And Peter H.S. has a 5-digit Slashdot UID! Clearly he knows what he's talking about, and couldn't possibly be wrong.
Yes, I know what I am talking about since I both use systemd and have read the systemd documentation. This is unlike you and the rest of the toxic systemd-haters who only repeat the party line as regurgitated by loony blogs, but hasn't bothered reading even the systemd man-pages.
systemd really is rock solid and amazingly secure by default. The fact that it uses "namespaces", "cgroups" and "capabilities" to protect long running system daemons, is far superior to what any other non-systemd distro have to offer.
While the systemd-haters are still wasting time trolling systemd-threads, their non-systemd distros slowly whither away by complete lack of development. But then again, does anybody actually care?
Until they have to debug a boottime issue (which crops up quite frequently in production environments with systemd).
You are just talking bullshit here. I have been using systemd for +4 years now and it has been rock stable. Besides, systemd systems are so much nicer to debug than distros glued together with shell scripts.
Just the fact that you can have full logging and the systemd tools working from initramfs is a vast improvement, and the systemd journal beats all other Linux logging options by a huge distance; field based filtering and monotonic timestamps are just great when debugging boot problems.
Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex. (the line shows all log entries from the previous boot with the syslog severity level "error" and above, try that with grep!).
Unfortunately, by then their strategy of subsuming other projects (sianara ntp, it was nice knowin' you)
You are seriously misinformed here; systemd provides a sNTPv4 client, not a ntp-server. It is a compile time option, so no distro ever needs to use it instead of their preferred sNTP-client. It is included in the systemd project for two main reasons; clock-less ARM boards and OS containers. Both have special timing needs since eg. an OS container can be "frozen" and "unfrozen" without warning. systemd provides them both with a solution so they don't gets confused by time jumps.
But perhaps you think choice is bad and there are too many sNTP clients so systemd developers should be banned from providing one?
, enforcing dependencies
Like what? systemd have extremely few external dependencies. And don't try the provable falsehood that systemd inserts "hard dependencies" in other projects like Gnome/KDE. That Gnome have had problems supporting non-systemd distros was because those distros didn't care to maintain ConsoleKit. Gnome kept on supporting CK despite it having been abandoned for +1½ year with no upstream to provide bug-fixes or security fixes.
But thanks to systemd, there are now several alternatives to ConsoleKit. Choice is good.
, making it more difficult to maintain alternatives (dropping support for biosdevname=0 for example) will have made it difficult if not impossible for those who wake up to switch to something that adheres to more sensible unix norms.
Again, you are really misinformed here; how can systemd ever make it harder for non-systemd distros that are using mdev or vdev or eudev?
If a non-systemd distro wants to use unpredictable network names they can do so. With systemd distros here is how you turn off predictable network interface names: http://www.freedesktop.org/wik...
Again, thanks to systemd the Linux ecosystem went from just having udev and mdev, to also having eudev and vdev and probably several more. So if you like choice, praise systemd for providing it.
Not necessarily. The alternative to no laws isn't bad laws.
As it is now companies can spew out insecure products with impunity and even silently drop any security support for devices consumers have just bought, not forgetting the classic tactic of not acknowledging security problems and just plain ignoring them. This can't go on.
Really, there ought to be some sensible minimum standards for commercial products that can be connected to the internet. This could include that the company had a decent policy for security fixes and a published contact point for people reporting such problems.
And how about a pre-published, minimum security support length, so that people buying a smartphone/router/etc. will know in advance how many years it will be supported with security fixes. There are "use by" dates on food, why not on all internet connected devices.
Yeah, I even found a man page that list all the man pages : "man systemd.index" and a index for all unit directives "man systemd.directives" with cross-references to the relevant man pages. Really useful stuff that shows the developers cares about end users.
Slashdot Mirror
EDF has been losing money not on generation but on building projects that had bad management practices. Generation is highly profitable, as most of the plants long paid for themselves and are generating pure profit at this point.
Some electricity generation is profitable because they have a de facto monopoly and can sell to consumers at artificially high prices. If they had to compete on market prices most nuclear reactors would sell electricity at a loss.
That is exactly the reason there isn't a free market working in France on electricity; it would bankrupt the nuclear industry.
The nuclear sector in France have state guaranteed profits. Even the new electricity tarif scheme with some market elements in it, ensures that they get guaranteed minimum price for the generated electricity, the difference being paid by French tax payers and consumers.
Regarding EDF's failure to build new reactors on time on budget; well, the entire nuclear industry suffers from this, including the ones in China and Russia. It basically means that new reactors will rely even more on state subsidies and regulation to operate.
French electricity prices and subsidization is highly complex, including extra subsidization for families below a certain income level. And now it is changing yet again. The new change will introduce a element of market pricing. This is why Moody's and Standard and Poor have been downgrading EDF stock:
https://www.moodys.com/researc...
Be wary of using simple charts of electricity prices across EU: the one you quoted includes various taxes too, so it doesn't reflect _production prices_ at all, only what the consumers pays, probably averaged heavily too, since the price structures are varying like different day and night prices etc. Some countries have high electricity taxes making their consumer prices high, even though the production price may be low.
If you look at production prices, nuclear power can't compete. This is also the reason why no one really builds new nuclear power plants in the US, since local laws often forbid passing above market prices to consumers.
There may be good reasons to have nuclear power plants, like the ability to make nuclear weapons, reduce CO2, etc., but they can't compete on production prices, so consumers and tax payers will have to foot the bill.
The electricity prices are still low in France thanks to government regulation, but they are scheduled to rise significantly over the next years. The prices have been artificially held low so that the French nuclear energy sector (EDF etc.) have been bleeding money and raking up debt like there is no tomorrow, while taxpayers have footed the rest of the bill.
So the French nuclear sector are also effectively subsidizing their nuclear power by making French tax payers pay the bill. Yes, they still have low electricity prices, but that is only because they pay more taxes on their wages to keep the electricity prices artificially low. This can't go on.
The move to reduce dependency on nuclear power is made because France is moving away from subsidized prices, so the consumers will pay more in line with what it actually cost to produce the energy directly instead of hiding the costs in higher taxes or forcing the utility companies to sell at too low prices.
The problem for the nuclear sector is that it is unable to compete on market prices. So if you want a more competitive and less regulated energy market in France, you have to reduce the reliance on nuclear power.
The main reason is cost. Nuclear power can't compete on price with neither fossil fuels nor renewable energy like solar or wind. So basically every french nuclear power station is a hole into which the consumers are shoveling money into.
You simply can't build or operate a nuclear reactor power station anywhere in the world that can compete on market prices.
For France, the ever more connected EU electricity grid means an ever increasing pressure on the energy sector to be able to compete on EU electricity prices. The long term prospects for nuclear energy to ever be able to compete on prices looks bleak, even if fossil fuel prices rises significantly.
In the meantime much more nimble energy technologies like solar and wind continues to make significant progress in cost and efficiency. And unlike nuclear power plants, they can quickly deploy the newest technology in the field.
So it really makes a lot of sense for France to lower its reliance on nuclear power and start to invest more in renewable energy resources.
All joking aside, historically that's exactly what happened! The crack of the Enigma in particular and German/Axis crypto in general, was kept very secret just to foist broken encryption onto the world.
The Enigma with Steckerbrett used with good operational procedures was actually practically unbreakable even in the decades after the war. While some aspects of the Enigma designed "leaked" info about its configuration, it was a sound design, and AFAIK, practically identically to what the allied used. That the allies could decrypt Enigma messages was almost entirely caused by bad German operational procedures and the capture of code books. Even today it is a massive computational effort to break historical Enigma messages.
So the countries receiving Enigmas could have had practically unbreakable crypto with the right operational procedures.
I read recently that the Allies made a policy of not telling about the decryption until long after the war, apparently so everyone would think we won by valor rather than by cheating. But what's (perversely) funny is that the UK rounded up as many machines as they could and "donated" them to third- world countries so that they, too, could enjoy the benefits of strong encryption.
No. The reason why the allies kept extremely mum about cracking the enigma was simply because they had learned the hard way that this was the right thing to do.
It goes back to the first world war when the British "Room 40" cracked German naval codes. The German navy knew nothing of this until W. Churchill published a history of the war where he "spilled the beans" about it. The German Navy and army where shocked when they learned how their crypto had been compromised and decided to strengthen their crypto to previously unheard levels. That is the reason why they bought and deployed the Enigma machines.
The Enigma was practically unbreakable at the time if used correctly, so it was by a thin margin that the Allies where able to decrypt Enigma messages. So they felt it was absolutely vital reveal nothing about their successes after the war, so future potential enemies didn't improved their crypto and crypto-procedures even more.
The conservatives are just getting their panties in a bunch because they can no longer demand "moral" state backed censorship of the net.
Hyperbolic claims are about SPAM not being allowed to be blocked, are just sad political attempts to institute state sponsored censorship through the backdoor.
Looking at V. Ford's homepage just says she unsurprisingly supports companies right to unlimited spamming of customers, something that the new rules also forbid.
Of course SPAM filtering is allowed under the new rules.
Maybe there is an EU member state where SPAM/UCE is legal, but in all EU countries I know of, it is illegal and therefore can be blocked. Not only is the act of spamming illegal, but since they almost always use criminal methods like mass hacking, that fact too is reason for blocking all such SPAM.
ISP default content filtering or state mandated content filtering of legal stuff will be prohibited. So the UK state dictated "opt out" filtering will be illegal, while Symantec's etc. individually enabled and user controlled content filtering will be allowed.
You sound like you have been badly informed by some punter site.
At first glance the new net neutrality rules looks very good. The "non-blocking" rules seems to make default and opt-out ISP porn-filtering illegal. If a site/service isn't illegal in one way or another, the ISP must not block it.
Sure, the ISP can offer various content filters as an opt in solution, leaving any such decisions to the individual where such decisions belongs, but the ISP can't "opt in" everybody, nor can any member state make any such filters mandatory.
From a free speech perspective that is a huge win on top of the network traffic net-neutrality rules.
I can't see anywhere if these rules are only binding within the EU, or if it is legal to block/throttle non-illegal sites and traffic from sites outside the EU. Does anybody know?
You mean one developer, who's known for throwing shit together in a crufty way, managed to convince three people at the "PNELV" by either boring them shitless or throwing a tantrum.
No, I mean many many kernel developers, including the guy who maintain all long term stable Linux kernels for the Linux-foundation. Basically the second guy besides Linus Torvalds that the LF employ.
I have seen zero kernel developers backing any other Linux init-system. In fact, the Linux developers seems to actually flee from the rather toxic systemd-hater camp that you and your juvenile behaviour are stellar examples of.
Seriously, who would ever work in a project with a poisonous guy like you?
[snip: about "journalctl -b -1 -p err"]
You are cherry-picking the one thing that isn't logged by most syslog daemons by default,, in a disingenious attempt to show that syslog is "worse", even though it is off by default because it is of little use. If we cared AT ALL to have the "log level" information, it would be logged.
I chose the example because it has proven really useful to me. The example will quickly show any serious error that may have cause a system to fail. Being able to filter out all boot-sessions that aren't relevant is really useful. Being able to see all serious errors on a system at a glance is really useful too. Being able to easily combine such queries into one is pure gold.
But there is so much more that syslog doesn't log. This brings on another fundamental problem with text logs; they are hard to parse for machines due to their lack of structures, and they become hard to parse for humans too if they contain too much information.
Monotonic and micro-precision timestamps are great, but they foul up the readability of syslog textfiles simply because they make the lines longer. So basically syslog can't put the same amount of logging info in the log files, not for direct technical reasons, but because the log file format is inadequate.
The systemd journal on the other hand, can easily be extended with ever more fields as needs arise. And it can do so without breaking userland!
Because another problem with the unstructured syslog text logs are that they have no programmatic API or even "labels" for each part of a logging entry. That means the very structure of the log entries has become a sort of API, so changing that structure by adding more information, and thousands of userland log-watcher scripts that rely on "cut" simply breaks down.
The discussions of the many limitations of syslog,
Fine. Then solve the problem where it should be solved, and add this to /etc/syslog. You systemd apparatchik like editing non-script-based config files, right?
Many of the problems can't be solved by adding features to syslog. If you want "metal-to-metal" logging you just got to design something like journald for so many technical reasons, including that the Linux kernel only accept one owner of /dev/log.
But as said, the most fundamental problems are the total lack of coordination between stuff in Linux. It is almost impossible to improve some things because of that. The Rsyslog team have fought valiantly over the years, but the sheer lethargy and no formal coordination means changes are hard to impossible.
The systemd team solved this problem in the most elegant way possible; they made a new logger that were 100% backwards compatible with syslog, but at the same time introduced radical new features. The end-users could user whatever option that suited them best, and userland didn't have to change a line of code, while still benefiting from the new features.
This way all the systemd Linux distros and userland programs can slowly migrate to using the new journald logging API. No "flag day" problems!
Now you can read those messages only using "less". You DID know that syslog has very flexible log routing and filtering capabilities, right?
I think the above examples greatly illustrate several problems with syslog text-files.
But first; despite spanning several lines, it isn't even remotely close to what "journalctl -b -
Systemd will fail in the long run. Systemd lovers are just like the windows fanatics of yester year. My company has thousands of Linux systems guess what none of them are moving to a distro the uses systemd and never will. We will still keep making money. And will have a freedom of choice. So go suck it systems lovers.
Why should I care that you don't use a systemd distro? If you are making money on Linux, great. If you are using eg. Slackware to do so, hey, that is great too. I respect mr. Volkerding and his way of making a distro.
I like freedom of choice and I think systemd provides exactly that. Even if you don't like it, you benefit from the fact that there now are several udev-implementations (before there was just udev and the limited mdev) and several ConsoleKit/systemd-logind implementations (before systemd there was only CK).
But apparently the freedom of choice doesn't include the right to choose systemd.
That is a major problem with the behaviour of the anti-systemd camp; they won't accept that highly skilled Linux developers (including Kernel developers) and experienced distro and system maintainers, thinks that systemd is superior to whatever else out there, and therefore chooses to build their distro around it.
This lack of accepting other peoples freedom of choice is why you are trolling a Debian thread, even though you don't use the distro and claim you never will.
So think about what you are actually doing before saying "freedom of choice" again.
Such as? I've never had any problems.
I adore the power of using sql queries on logs.
How does journalctl fare in terms of having a trigger set up to automatically do things with logs when they're inserted?
The classic problem was speed. A DB was fine for storing and analysing, but could be severe bottleneck for log sinks.
It isn't so great for local system logging either since DB's tend to appear rather late in the boot sequence.
With journald you can have system logging before the rootfs is even mounted, and since both systemd and journald can pivot back to initramfs after the rootfs has been unmounted, you can potentially have logging after that.
These days it seems that people are using a mixture of DB's and heavily data massaged text logs (JSON etc) combined with a special index (Splunk etc).
There will never a single log storage solution for all, since the tools chosen will reflect the problems trying to be solved. For some it is auditing that is important, for others it is analysing website usage.
But since systemds journal is structured and field based, it is very easy to convert its log entries to standard JSON etc that consistently fits other storage means. A huge improvement over the many different syslog implementations.
Re: triggers. You don't use "journalctl" for that, but the API/libraries/language bindings. systemd provides a really good and well documented framework for making triggers, but don't provide them as such. You can have instantly triggered events on file systems that supports it.
"man sd_journal_get_events" documents the C API:
http://www.freedesktop.org/sof...
But there are also Ruby, Python, Go bindings etc. All in all I think systemd/journald is a major upgrade when it comes to log watchers; stable API, field based filtering, many language bindings, instant notifications etc.
Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex. (the line shows all log entries from the previous boot with the syslog severity level "error" and above, try that with grep!).
just playing around with "journalctl" for 10 minutes convinced me wholly.
So you've never tried using rsyslog to log to a database then?
Yes, so I know the many limitations of doing so. It is of course of interest to know that Rainer started the Rsyslog project exactly to overcome the many problems with the old syslog(3) interface, especially the problems with flat file text logs.
I have much respect for the Rsyslog developers work and it certainly weren't their fault they couldn't fix all the problems they set out to solve. So I am glad that Rsyslog now can read/write systemd journal files, meaning that it can be used as a log sink (at least for simpler cases) without regressing to using flat text log files.
Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex.
That statement alone shows the core problem with the systemd evangelists: you don' t want to learn generic tools, and instead want to use single-purpose, monolithic[1] apps.
"systemtctl" is a first class classic Linux/Unix tools that works together with all the standard Linux tools like sed, awk, grep, less, tee and what not.
It isn't interactive, it isn't chatty on success, can be piped etc, just like all the good ole GNU stuff. Sure, it can read binary text files like the journal, but so can "last" that is required to be Posix compliant (used to read the utmp/wtmp binary log files). And what about zgrep?
The systemd journal file format (basically an appended text file with non-standard delimeters+index) is fully documented and have excellent language bindings, making it trivial to make eg. Python scripts that read/writes directly into the journal. So it is trivial to make a "jgrep" or a "jless" that can directly read the journal if that is what you want.
The point is that "field" based logging is superior to the unstructured text dumps that syslog makes.
The point of what you call "faffing around with grep and regex" is that those tools are not difficult to use, and once you are familiar with the basics you now have a general tool you can apply to any unexpected situation.
Come on, claiming that regular expressions are easy is laughable. The old joke "I had problem. I decided to solve it with regex. Now I have two problems" is still true.
Not talking about that people should know the difference between regular and extended expressions, and that each and every tool uses its own maddening variation. Basically, if you don't use regular expressions as part of your everyday job, you are unable to use it without heavy man-page consulting for just the basic syntax.
I seriously doubt that any more than a tiny fraction of Linux users are able to whip out an even moderately complex regex. And that means the vast majority of Linux users can't filter their logs to any serious degree. It is so sad to see how people are literally trawling through the logs, reading them as a book in order to find problems. People are even using "vi" to do it, yikes.
systemd's journal basically solves this problem for good for Linux newbies. It is fun to see how productive people can become with "journactl" after a 10 minute introduction.
For power users, the field based approach is immensely powerful too. If you remember how Rsyslog started a decade ago, it was exactly to overcome the many limitations of flat file text logs.
syslog severity level "error" and above
I have never even remotely needed to filter events by syslog(3)'s "level" bits - it's not a very reliable filter, as app can be inconsistent in what LOG_* flag they use.
It is a superb way to filter from both "that boot only" and "this severity only". One reason why you probably haven't tried it is because this is very hard to do using generic tools using flat file syslog text logs.
Filtering on the facility (source) or time is far more useful. If you find that particular command to be useful, then great - which would be a good example of how use-cases can vary a *lot* depending on what you're doing.
Even this is something journald does so much better than syslog; There is kernel guarantee that the source is always is always what it claims to be. Same with what program generated the log entry. It can even distinguish between two instances of the same program running simultaneously since each and every log entry is stamped with a unique id (and session ID, and machine ID so you can trail logs even if the hostname/IP changes or across multiple machines and OS containers).
As for time based fil
Systemd is terribly unstable and rolls state back for trivial reasons. Those of us in charge of data centers see the issues, your laptop or home pc is not a viable model of reality.
What "state" are you talking about. This is Linux/Unix, not a transactional OS. systemd doesn't perform "roll backs". What trivial reason? Maybe that could explain what you are trying to say. It really sounds like you have no personal experience with systemd nor have read anything about it.
You are talking bullshit here, we've been testing systemd for 6 months and it is unstable, rolls the system back to start state for trivial reasons. Not to mention needing all kinds of shims for the parts that haven't even been written yet so it could "function" in a current system. What a bunch of badly designed over complicated garbage
There are no "shims" necessary to run systemd. On Debian there is "logind-shim", but no one should use that instead of the proper systemd-logind.
Comments like that, and your bizarre claim of " rolls the system back to start state" makes me suspect that you don't have actual personal understanding and experience of systemd management.
Sure, truly understanding systemd require some serious study, something way too many have neglected, thinking they could just wing it when time came. The payback for the time spend studying is that systemd also have some serious cool technology that is far superior to everything else in Linux/Unix land.
On a VM on your mom's MacBook that you take down to Starbuck's in a record bag slung over the crossbar of your fixie.
It is exactly because the systemd-hater camp apparently consist of technical illiterates like you, that they have lost each and every technical argument on all major distros. Ad hominem attacks and poisonous threats and trolling systemd threads are all you can do. Almost all volunteer developers have left the non-systemd camp because of its toxic atmosphere where attacking open source developers and users are as normal as breathing air.
Think about it; the anti-systemd faction couldn't even muster 5 Debian developers to sponsor a GR bill to overturn the technical committees decision of making systemd default init.
The negative, hate-driven anti-systemd campaign have resulted in that 100% of all commercial general Linux distros and most of the community driven distros are behind systemd and are supporting it. Talk about a losing campaign strategy.
No, it's not possible for systemd to have a bug. Our very own Peter H.S. told us that systemd is "rock stable". "Rock stable" software systems don't have bugs! And Peter H.S. has a 5-digit Slashdot UID! Clearly he knows what he's talking about, and couldn't possibly be wrong.
Yes, I know what I am talking about since I both use systemd and have read the systemd documentation. This is unlike you and the rest of the toxic systemd-haters who only repeat the party line as regurgitated by loony blogs, but hasn't bothered reading even the systemd man-pages.
systemd really is rock solid and amazingly secure by default. The fact that it uses "namespaces", "cgroups" and "capabilities" to protect long running system daemons, is far superior to what any other non-systemd distro have to offer.
While the systemd-haters are still wasting time trolling systemd-threads, their non-systemd distros slowly whither away by complete lack of development. But then again, does anybody actually care?
Coward!
The journal is brilliant, anyone who says it isn't needs their head examined.
Yes, the journal really is brilliant. It just solves so many decade old logging Linux problems, and make hard stuff very easy.
I was sceptical about binary log files when I first heard about it, but just playing around with "journalctl" for 10 minutes convinced me wholly.
Until they have to debug a boottime issue (which crops up quite frequently in production environments with systemd).
You are just talking bullshit here. I have been using systemd for +4 years now and it has been rock stable.
Besides, systemd systems are so much nicer to debug than distros glued together with shell scripts.
Just the fact that you can have full logging and the systemd tools working from initramfs is a vast improvement, and the systemd journal beats all other Linux logging options by a huge distance; field based filtering and monotonic timestamps are just great when debugging boot problems.
Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex. (the line shows all log entries from the previous boot with the syslog severity level "error" and above, try that with grep!).
Unfortunately, by then their strategy of subsuming other projects (sianara ntp, it was nice knowin' you)
You are seriously misinformed here; systemd provides a sNTPv4 client, not a ntp-server. It is a compile time option, so no distro ever needs to use it instead of their preferred sNTP-client. It is included in the systemd project for two main reasons; clock-less ARM boards and OS containers. Both have special timing needs since eg. an OS container can be "frozen" and "unfrozen" without warning. systemd provides them both with a solution so they don't gets confused by time jumps.
But perhaps you think choice is bad and there are too many sNTP clients so systemd developers should be banned from providing one?
, enforcing dependencies
Like what? systemd have extremely few external dependencies. And don't try the provable falsehood that systemd inserts "hard dependencies" in other projects like Gnome/KDE.
That Gnome have had problems supporting non-systemd distros was because those distros didn't care to maintain ConsoleKit. Gnome kept on supporting CK despite it having been abandoned for +1½ year with no upstream to provide bug-fixes or security fixes.
But thanks to systemd, there are now several alternatives to ConsoleKit. Choice is good.
, making it more difficult to maintain alternatives (dropping support for biosdevname=0 for example) will have made it difficult if not impossible for those who wake up to switch to something that adheres to more sensible unix norms.
Again, you are really misinformed here; how can systemd ever make it harder for non-systemd distros that are using mdev or vdev or eudev?
If a non-systemd distro wants to use unpredictable network names they can do so.
With systemd distros here is how you turn off predictable network interface names:
http://www.freedesktop.org/wik...
Again, thanks to systemd the Linux ecosystem went from just having udev and mdev, to also having eudev and vdev and probably several more. So if you like choice, praise systemd for providing it.
Not necessarily. The alternative to no laws isn't bad laws.
As it is now companies can spew out insecure products with impunity and even silently drop any security support for devices consumers have just bought, not forgetting the classic tactic of not acknowledging security problems and just plain ignoring them. This can't go on.
Really, there ought to be some sensible minimum standards for commercial products that can be connected to the internet. This could include that the company had a decent policy for security fixes and a published contact point for people reporting such problems.
And how about a pre-published, minimum security support length, so that people buying a smartphone/router/etc. will know in advance how many years it will be supported with security fixes. There are "use by" dates on food, why not on all internet connected devices.
Yeah, I even found a man page that list all the man pages : "man systemd.index" and a index for all unit directives "man systemd.directives" with cross-references to the relevant man pages. Really useful stuff that shows the developers cares about end users.