You're right insofar as changing from a SysV-style init to SystemD obviously presents opportunity for boot failure.
However, to me that would logically mean that you have broken/unimplemented SystemD unit files. So either fix them or wait until someone else does. It's not an argument against SystemD, it's an argument against bugs and/or poor transition implementation. I would point to the Windows XP x64 switchover as a prime example of that. Despite which, x86-64 is ubiquitous now.
I'm not going to bother saying anything about Lennart or other core systemd developers since it's been widely established that they have proven to be disagreeable on numerous occasions.
What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is. My systemd machines are ready to go much faster than any bash-script based init system and writing a new unit file for some daemon that lacks one already is easy peasy.
The only place where I feel it falls somewhat short is in systemd-networkd which currently lacks good support for policy routing. Fortunately, it doesn't bar me from running a post-network-up script to do command-line based route installation, so until it develops that functionality, that's what I'm doing.
Copyright of the Linux Kernel is actually spread across all its contributors, The Linux Foundation doesn't have any overriding ownership. Though of course any particular author(s) code could be excised from it in order to make their copyright irrelevant.
In any case though, the copyright holders get to determine what licenses or permissions to grant over the work, they don't get to then decide how the license should be interpreted - that's up to an arbitrator or a court. If Canonical's lawyers are incorrect in their interpretation then someone will need to bring a court case to have it resolved.
a score of 5 for this tired old ignorant shit? Alright, let's get cracking.
RA, aka. ICMP router advertisement. Abandoned circa 1970 as a "bad idea". It was a colossally bad idea in the 90's, and f'ing suicidally bad in 2000+. Yeah, let's trust whoever the f*** on the cable claims to be a router and send it our traffic. Oh, to protect my network(s) from that brain damage, I have to buy new switches that support "RA Guard"
Right, because DHCP totally solves spoofing problems yeah?
They didn't like DHCP. So "no f***ing DHCP in IPv6!" DHCPv6 is a bolt-on, staple-on, and bandaid addition to IPv6. It's a horribly incomplete shadow of DHCPv4, and still requires an RA tell you to use it.
No it isn't. You can do practically everything that DHCPv4 does with DHCPv6. Yes you should send an RA, so what? DHCPv4 is as much if not more of a bolt-on than DHCPv6 is (in so far as it's absolutely not part of the protocol stack whatsoever)
SLAAC... originally 80bit prefix plus 48bit MAC. They ignored the fact that ethernet is not the only technology in the universe. That was later amended (breaking older stacks) to 64bits. The entire purpose for the vast over-simplification of address selection (for tiny embeded systems with limit RAM/ROM/CPU) became moot 7sec into the IPng committee's existance -- IPSec shoots all three in the head, repeatedly, with artillery. Everything supports privacy extensions these days, so the logic for random address generation and duplicate address detection is there -- and rather trivial. Yet it, and SLAAC, demands the prefix-length be 64. Just to put that silliness in perspective, that's a single LAN with every ethernet device ever created (that will ever be created) in it 65,536 times over.
Just to put YOUR silliness in perspective: the remaining number of bits is 2^61 (within 2000::/3 obviously) which comes to 2,305,843,009,213,693,952/64s. Get a damn sense of perspective. As far as "older stacks" go... clearly not anything seriously used in production today.
This leads nicely into the blindness to history... a 64bit LAN is pure lunacy. Today and likely for several decades. But we "have an infinite amount of address space." Actually, NO, it is, in fact, quite finite: 128bits, to be exact. If we carve it up with the same pez-like abandon as the early IPv4 assignments, it will be even less "infinite". Sure, we can change the way we do things "with the next::/8", but that dooms us to live with the colossal stupid of this::/8 for ever. Again, dooming us (and our children's great grand-children) to live with our bullshit. We did a lot of stupid things with IPv4; and we're doing them all over again with IPv6.
No, your failure to grasp the scale of numbers is pure lunacy. If we somehow manage to fuck up 2000::/3, there's several times the size of the current global IP space waiting to be spun up with the flick of a pen, so we have plenty of opportunity to make mistakes.
This is really simple. Put a label on the food to identify it as genetically modified. Thou dost protest too much. Why so much resistance?
No, it's really stupid.
Take two species of plant, pollinate one with the other. BOOM, genes from both plants are recombined to form a new unique plant. genetic modification.
Suit yourself. You can't tell consumers they don't get to know what's in their food without consequences.
They do get to know what is in the food, all the ingredients are right in the packet.
the operative word in GMO is the G - if you'd like a full readout of the genes of whatever it is you're eating, go take it to be sequenced - it matters not one iota to your digestion, what does are the proteins, starches etc that are expressed (or not) as a result of those genes, and the information is right there on the packet.
whois indicates the original owner still controls the domain, the server itself is Rackspace owned whereas SOCA's own website is run themselves via Connect Internet Solutions Ltd. - throw in the fact that SOCA haven't made any announcement or press release regarding the alleged takedown and the whole thing looks like a setup, I call shenanigans.
I roll my own Windows builds of Firefox and have been using Win64 versions since before FF4 actually came out; the difference is really minimal; I use 64-bit Flash (square) and Java, everything works and it's native.
Currently there is a patch in the works to enable Firefox x64 to use 32bit plugins via the wrapper, which I get the feeling will probably encourage Adobe to not bother releasing a "proper" x64 Flash.
First Slashdot posts a load of crap about how nenolod supposedly cracked the Motorola Android certs (hint: he didn't, it was a troll) and now you're quoting bullshit from some no-name site as gospel, go ask someone who actually works for Mozilla what's actually going to be in Firefox 5 and you'll discover that most of that article is complete and utter wank.
As a non-Hungarian who spends a rather large amount of time in Hungary.
This media law is going to get challenged at the first possible opportunity by someone like Magyar Hírlap and the case will end up being taken to the EU level and Fidesz will quite probably end up in a semi-embarassing climbdown that they will no doubt try to spin in order to save face.
Totalitarian laws are scary only when they have genuine teeth... Hungary as a country does not have these sort of teeth, and this Media law will only descend into debacle in the coming months and years.
Depends if you're talking about the dumb ones that you just provision with something like Gemalto's Card Admin or the ones that you can actually program applications for and write to the card.
In any case, EMV smartcards aren't mere "flash drives"
I wrote a Windows software version of the CAP/DPA card readers; entering the PIN does make a difference; the ARQC generated by the smartcard differs if the PIN hasn't been submitted, the same will apply in a DDA transaction carried out at a terminal; the PIN bypass is only truly going to work if the terminal or card only supports SDA, otherwise, the bank's back end can check whether the PIN was issued or not.
Actually that's only true for SDA (Static Data Authentication) smartcards (or terminals incapable of performing DDA) - if the auth process uses DDA then the ARQC generated by the EMV card will be different and the bank will thus know that the card was not issued a PIN.
I doubt any of the UK banks are still issuing SDA cards, however, whether a merchant's terminal supports DDA is another issue.
In any case, it's a heck of a lot of effort and risk to go to when fraudsters by-and-large can have a much easier time engaging in CNP transactions.
depends if the spammer wants control of the account over the long term or simply wants to do a hard and fast smash 'n' grab on the account.
In any case, this could easily be mitigated with a captcha or similar.
This is a terrible analogy; they're advertising a rate of download which you will probably not get, nonetheless, whilst whatever you want to download might well take longer than expected, you'll still get your download.
So here's an analogy that works; the advertised weight of the chips/burger/whatever is exactly the same, what you're being told is that you can expect to spend 10 minutes consuming it when in reality the only people who are going to spend that long on it are small children; either way you still got your bag of chips, you're just polishing them off faster than you'd expect.
the leaked builds you refer to are coming out almost daily my friend, it's like a live action stream of ROMs, the majority of which are, for the most part, usable.
The thing is, the ones that see the light of day to the average punter are all cooked ROMs of course, adulterated with additional shit and the cook's branding thrown in, I hate the bloody things, and I say that as the person jointly responsible for the patched SPL that allows you to flash them.
HTC's "Manila" interface is a today item that overlays and essentially replaces the whole kaboodle - it also has its hooks in the gwes EXE (GUI) in order to modify the device's interface, the fancy 3D shit is a capability of the hardware.
The way that's achieved is simple enough - get yourself a copy of Platform Builder, read the source... you can in fact download the CE version freely, which is (usually) close enough to WM that you can make something.
Actually, you appear to be confusing "open platform" with "open phone"
The HTC manufactured Android devices aren't open in any way shape or form, all ROM updates are RSA signed, and the only way to "free" the device from these restrictions is by either exploiting something or alternatively, flashing to an old ROM that can be exploited.
You're right insofar as changing from a SysV-style init to SystemD obviously presents opportunity for boot failure.
However, to me that would logically mean that you have broken/unimplemented SystemD unit files. So either fix them or wait until someone else does. It's not an argument against SystemD, it's an argument against bugs and/or poor transition implementation. I would point to the Windows XP x64 switchover as a prime example of that. Despite which, x86-64 is ubiquitous now.
I'm not going to bother saying anything about Lennart or other core systemd developers since it's been widely established that they have proven to be disagreeable on numerous occasions.
What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is. My systemd machines are ready to go much faster than any bash-script based init system and writing a new unit file for some daemon that lacks one already is easy peasy.
The only place where I feel it falls somewhat short is in systemd-networkd which currently lacks good support for policy routing. Fortunately, it doesn't bar me from running a post-network-up script to do command-line based route installation, so until it develops that functionality, that's what I'm doing.
Copyright of the Linux Kernel is actually spread across all its contributors, The Linux Foundation doesn't have any overriding ownership. Though of course any particular author(s) code could be excised from it in order to make their copyright irrelevant.
In any case though, the copyright holders get to determine what licenses or permissions to grant over the work, they don't get to then decide how the license should be interpreted - that's up to an arbitrator or a court. If Canonical's lawyers are incorrect in their interpretation then someone will need to bring a court case to have it resolved.
a score of 5 for this tired old ignorant shit? Alright, let's get cracking.
RA, aka. ICMP router advertisement. Abandoned circa 1970 as a "bad idea". It was a colossally bad idea in the 90's, and f'ing suicidally bad in 2000+. Yeah, let's trust whoever the f*** on the cable claims to be a router and send it our traffic. Oh, to protect my network(s) from that brain damage, I have to buy new switches that support "RA Guard"
Right, because DHCP totally solves spoofing problems yeah?
They didn't like DHCP. So "no f***ing DHCP in IPv6!" DHCPv6 is a bolt-on, staple-on, and bandaid addition to IPv6. It's a horribly incomplete shadow of DHCPv4, and still requires an RA tell you to use it.
No it isn't. You can do practically everything that DHCPv4 does with DHCPv6. Yes you should send an RA, so what? DHCPv4 is as much if not more of a bolt-on than DHCPv6 is (in so far as it's absolutely not part of the protocol stack whatsoever)
SLAAC... originally 80bit prefix plus 48bit MAC. They ignored the fact that ethernet is not the only technology in the universe. That was later amended (breaking older stacks) to 64bits. The entire purpose for the vast over-simplification of address selection (for tiny embeded systems with limit RAM/ROM/CPU) became moot 7sec into the IPng committee's existance -- IPSec shoots all three in the head, repeatedly, with artillery. Everything supports privacy extensions these days, so the logic for random address generation and duplicate address detection is there -- and rather trivial. Yet it, and SLAAC, demands the prefix-length be 64. Just to put that silliness in perspective, that's a single LAN with every ethernet device ever created (that will ever be created) in it 65,536 times over.
Just to put YOUR silliness in perspective: the remaining number of bits is 2^61 (within 2000::/3 obviously) which comes to 2,305,843,009,213,693,952 /64s. Get a damn sense of perspective. As far as "older stacks" go... clearly not anything seriously used in production today.
This leads nicely into the blindness to history... a 64bit LAN is pure lunacy. Today and likely for several decades. But we "have an infinite amount of address space." Actually, NO, it is, in fact, quite finite: 128bits, to be exact. If we carve it up with the same pez-like abandon as the early IPv4 assignments, it will be even less "infinite". Sure, we can change the way we do things "with the next ::/8", but that dooms us to live with the colossal stupid of this ::/8 for ever. Again, dooming us (and our children's great grand-children) to live with our bullshit. We did a lot of stupid things with IPv4; and we're doing them all over again with IPv6.
No, your failure to grasp the scale of numbers is pure lunacy. If we somehow manage to fuck up 2000::/3, there's several times the size of the current global IP space waiting to be spun up with the flick of a pen, so we have plenty of opportunity to make mistakes.
"amplified the DNA"
Sounds Legit.
This is really simple. Put a label on the food to identify it as genetically modified. Thou dost protest too much. Why so much resistance?
No, it's really stupid. Take two species of plant, pollinate one with the other. BOOM, genes from both plants are recombined to form a new unique plant. genetic modification.
Suit yourself. You can't tell consumers they don't get to know what's in their food without consequences.
They do get to know what is in the food, all the ingredients are right in the packet. the operative word in GMO is the G - if you'd like a full readout of the genes of whatever it is you're eating, go take it to be sequenced - it matters not one iota to your digestion, what does are the proteins, starches etc that are expressed (or not) as a result of those genes, and the information is right there on the packet.
according to a commenter elsewhere, they apparently phoned SOCA's press office and asserted it to be genuine, so, perhaps I stand corrected.
whois indicates the original owner still controls the domain, the server itself is Rackspace owned whereas SOCA's own website is run themselves via Connect Internet Solutions Ltd. - throw in the fact that SOCA haven't made any announcement or press release regarding the alleged takedown and the whole thing looks like a setup, I call shenanigans.
I roll my own Windows builds of Firefox and have been using Win64 versions since before FF4 actually came out; the difference is really minimal; I use 64-bit Flash (square) and Java, everything works and it's native. Currently there is a patch in the works to enable Firefox x64 to use 32bit plugins via the wrapper, which I get the feeling will probably encourage Adobe to not bother releasing a "proper" x64 Flash.
First Slashdot posts a load of crap about how nenolod supposedly cracked the Motorola Android certs (hint: he didn't, it was a troll) and now you're quoting bullshit from some no-name site as gospel, go ask someone who actually works for Mozilla what's actually going to be in Firefox 5 and you'll discover that most of that article is complete and utter wank.
Since when did ElGamal private keys fit into a single tweet? I don't believe for a second that Motorola were using a 240bit key, I call bullshit.
As a non-Hungarian who spends a rather large amount of time in Hungary.
This media law is going to get challenged at the first possible opportunity by someone like Magyar Hírlap and the case will end up being taken to the EU level and Fidesz will quite probably end up in a semi-embarassing climbdown that they will no doubt try to spin in order to save face.
Totalitarian laws are scary only when they have genuine teeth... Hungary as a country does not have these sort of teeth, and this Media law will only descend into debacle in the coming months and years.
Depends if you're talking about the dumb ones that you just provision with something like Gemalto's Card Admin or the ones that you can actually program applications for and write to the card. In any case, EMV smartcards aren't mere "flash drives"
I wrote a Windows software version of the CAP/DPA card readers; entering the PIN does make a difference; the ARQC generated by the smartcard differs if the PIN hasn't been submitted, the same will apply in a DDA transaction carried out at a terminal; the PIN bypass is only truly going to work if the terminal or card only supports SDA, otherwise, the bank's back end can check whether the PIN was issued or not.
Actually that's only true for SDA (Static Data Authentication) smartcards (or terminals incapable of performing DDA) - if the auth process uses DDA then the ARQC generated by the EMV card will be different and the bank will thus know that the card was not issued a PIN. I doubt any of the UK banks are still issuing SDA cards, however, whether a merchant's terminal supports DDA is another issue. In any case, it's a heck of a lot of effort and risk to go to when fraudsters by-and-large can have a much easier time engaging in CNP transactions.
Um, when data is stolen, it's copied, you don't copy it and then delete it, that's going to alert the user that you're collecting information.
depends if the spammer wants control of the account over the long term or simply wants to do a hard and fast smash 'n' grab on the account. In any case, this could easily be mitigated with a captcha or similar.
This essentially comes down to who can kick off the other logins first... the real user or the spam program. My money's on the program.
This is a terrible analogy; they're advertising a rate of download which you will probably not get, nonetheless, whilst whatever you want to download might well take longer than expected, you'll still get your download. So here's an analogy that works; the advertised weight of the chips/burger/whatever is exactly the same, what you're being told is that you can expect to spend 10 minutes consuming it when in reality the only people who are going to spend that long on it are small children; either way you still got your bag of chips, you're just polishing them off faster than you'd expect.
the new, improved RU-Pentium
the leaked builds you refer to are coming out almost daily my friend, it's like a live action stream of ROMs, the majority of which are, for the most part, usable. The thing is, the ones that see the light of day to the average punter are all cooked ROMs of course, adulterated with additional shit and the cook's branding thrown in, I hate the bloody things, and I say that as the person jointly responsible for the patched SPL that allows you to flash them.
HTC's "Manila" interface is a today item that overlays and essentially replaces the whole kaboodle - it also has its hooks in the gwes EXE (GUI) in order to modify the device's interface, the fancy 3D shit is a capability of the hardware. The way that's achieved is simple enough - get yourself a copy of Platform Builder, read the source... you can in fact download the CE version freely, which is (usually) close enough to WM that you can make something.
Actually, you appear to be confusing "open platform" with "open phone" The HTC manufactured Android devices aren't open in any way shape or form, all ROM updates are RSA signed, and the only way to "free" the device from these restrictions is by either exploiting something or alternatively, flashing to an old ROM that can be exploited.
http://www.channelregister.co.uk/2009/02/05/windows_xp_7_vista_upgrade/