Sorry, forgot about that one. While it's true that AES is broken, the attack in question is currently quite impractical since it requires a 2^88 data space
But if it's power enough to record audio and video it would probably be good enough for surveillance, upload can be done later when the user turns the phone on.
Does not the supposed realibility of VMS have more to do with the hardware (VAX) than the quality of the software (VMS), afaik the VAX could hot-swap cpu:s and ram live if the hw detected a failure.
Yes, because those that make lots of money off those meth houses will just idly stand be and see their whole business go down the drain and will not implement any countermeasure at all, no sir!
No this would save exactly 0 lives. Since the bombmakers do know that these sensors will be deployed they will of course take counter measures to avoid spilling the chemicals down the drainage where they are actually working.
ok, that link went wrong for some reason... Anyways, It turns out that I was wrong. The _main_ reason for Upstart was to make the starting of daemons event-based:
3.1.2.3 Upstart's Design: Why It Is Revolutionary
It was necessary to outline the limitations of the SysV and dependency-based init systems to appreciate why Upstart is special...
Upstart is revolutionary as it recognises and was designed specifically for a dynamic system. It handles asynchronicity by emitting events. This too is revolutionary.
Upstart emits "events" which services can register an interest in. When an event -- or combination of events -- is emitted that satisfies some service's requirements, Upstart will automatically start or stop that service. If multiple jobs have the same "start on" condition, Upstart will start those jobs ''in parallel''. To be manifest: Upstart handles starting the "dependent" services itself - this is not handled by the service file itself as it is with dependency-based systems.
Further, Upstart is being guided by the ultimate arbiter of hardware devices: the kernel.
In essence, Upstart is an event engine: it creates events, handles the consequences of those events being emitted and starts and stops processes as required. Like the best Unix software, it does this job very well. It is efficient, fast, flexible and reliable. It makes use of "helper" daemons (such as the upstart-udev-bridge and the upstart-socket-bridge) to inject new types of events into the system and react to these events. This design is sensible and clean: the init system itself must not be compromised since if it fails, the kernel panics. Therefore, any functionality which is not considered "core" functionality is farmed out to other daemons.
So if say apache dies due to OOM or simply a segfault you would rather get a mail and have your site down until you can put it up manually? You can see no benefit of daemon respawning ever? And who said that you couldn't be notified?
Faster boot might be one of the advantages of Upstart but it's not the main reason for it's existence. The main idea behind Upstart is to monitor and respawn daemons that hangs/segfaults.
Yeah sorry about that. Have seen GCC throw warnings on the few ocassions where I did similar things in error so I was temporarely unaware of the paranthesis supressing the warning. Something that I *should* know since I use it myself on several occasions (with fread and so on).
However a lint type of code analyzer should imho have a flag to enable warnings in these circumstanses.
Strange that the installer script doesn't refuse to run if it detects that it's already installed? That should solve the problem even for stupid admins.
Yeah I found that out some seconds ago. I did try it with GCC myself and since the uid=0 is wrapped inside their own parenthesis GCC does not throw off a warning evne on -Wextra, and a lint like cppcheck did not complain either (which pissed me off since they *should* warn about assignments in if statements if I tell it to report verbose warnings).
I thought so too, but apparently by wrapping the statement in parenthesis "(uid=0)" the compiler warning goes away, not even -Wall -Wextra shows a warning then.
Slashdot Mirror
all of those require windows.
At the moment yes, nothing is set in stone here, it's not like it's impossible for these software's to be ported if the demand comes.
Still AFAIK if you pillage and rape in another country then that country will have to have you extradited so _they_ can charge you for those crimes.
In which country is that illegal?
I don't see what you did there.
Which is why he wrote "IE on Windows XP".
Sorry, forgot about that one. While it's true that AES is broken, the attack in question is currently quite impractical since it requires a 2^88 data space
There is no faster than brute force attack for AES, unless you modify the algorithm to have less rounds but then it's no longer AES.
But if it's power enough to record audio and video it would probably be good enough for surveillance, upload can be done later when the user turns the phone on.
Does not the supposed realibility of VMS have more to do with the hardware (VAX) than the quality of the software (VMS), afaik the VAX could hot-swap cpu:s and ram live if the hw detected a failure.
A week? Try Gentoo.
Yes, because those that make lots of money off those meth houses will just idly stand be and see their whole business go down the drain and will not implement any countermeasure at all, no sir!
No this would save exactly 0 lives. Since the bombmakers do know that these sensors will be deployed they will of course take counter measures to avoid spilling the chemicals down the drainage where they are actually working.
Probably not any one that is allowed to talk.
Or rather that if you screw with the NSA's budget and storage center you'll never be found again
ok, that link went wrong for some reason... Anyways, It turns out that I was wrong. The _main_ reason for Upstart was to make the starting of daemons event-based:
3.1.2.3 Upstart's Design: Why It Is Revolutionary
It was necessary to outline the limitations of the SysV and dependency-based init systems to appreciate why Upstart is special...
Upstart is revolutionary as it recognises and was designed specifically for a dynamic system. It handles asynchronicity by emitting events. This too is revolutionary.
Upstart emits "events" which services can register an interest in. When an event -- or combination of events -- is emitted that satisfies some service's requirements, Upstart will automatically start or stop that service. If multiple jobs have the same "start on" condition, Upstart will start those jobs ''in parallel''. To be manifest: Upstart handles starting the "dependent" services itself - this is not handled by the service file itself as it is with dependency-based systems.
Further, Upstart is being guided by the ultimate arbiter of hardware devices: the kernel.
In essence, Upstart is an event engine: it creates events, handles the consequences of those events being emitted and starts and stops processes as required. Like the best Unix software, it does this job very well. It is efficient, fast, flexible and reliable. It makes use of "helper" daemons (such as the upstart-udev-bridge and the upstart-socket-bridge) to inject new types of events into the system and react to these events. This design is sensible and clean: the init system itself must not be compromised since if it fails, the kernel panics. Therefore, any functionality which is not considered "core" functionality is farmed out to other daemons.
So if say apache dies due to OOM or simply a segfault you would rather get a mail and have your site down until you can put it up manually? You can see no benefit of daemon respawning ever? And who said that you couldn't be notified?
Depends, there's quite a lot of things called init :-)
http://upstart.ubuntu.com/cookbook/#id66
Could you elaborate on your problems? I have written Upstart files for all our software without any need for patches etc.
Faster boot might be one of the advantages of Upstart but it's not the main reason for it's existence. The main idea behind Upstart is to monitor and respawn daemons that hangs/segfaults.
Wouldn't that be a brickberry?
Yeah sorry about that. Have seen GCC throw warnings on the few ocassions where I did similar things in error so I was temporarely unaware of the paranthesis supressing the warning. Something that I *should* know since I use it myself on several occasions (with fread and so on). However a lint type of code analyzer should imho have a flag to enable warnings in these circumstanses.
Strange that the installer script doesn't refuse to run if it detects that it's already installed? That should solve the problem even for stupid admins.
Yeah I found that out some seconds ago. I did try it with GCC myself and since the uid=0 is wrapped inside their own parenthesis GCC does not throw off a warning evne on -Wextra, and a lint like cppcheck did not complain either (which pissed me off since they *should* warn about assignments in if statements if I tell it to report verbose warnings).
I thought so too, but apparently by wrapping the statement in parenthesis "(uid=0)" the compiler warning goes away, not even -Wall -Wextra shows a warning then.