Nope, its true. I used to work for a US owned company in Australia - because of US law, we had to do everything in accordance with Sarbanes–Oxley. It was a royal pain in the ass - 100% pure bureaucracy - and just about doubled the work required to do most of our tasks.
I'm current working for a US company in Australia, and I never have to think about SOX. We automated all of the SOX stuff into the background, so day to day I work oblivious to these things.
Didn't you have automation and process improvement to do the same?
Funny how they advertise 20 years but promise only 3.
At a $60 price tag, that doesn't boost my confidence in their product. If they are going to claim 20 years, they should have a warranty of at least between 10 and 15 years.
In many jurisdictions, you will find that statuary warranty laws mean that a lamp failing after just 3-4 years can be replaced free regardless of manufacturer warranty.
In my jurisdiction (AU) as well as others (eg EU), law mandates that a device should last as long as is reasonably expected and advertised. If they advertise it as lasting 20y but it fails after 5, they're going to find consumer agencies breathing down their backs to replace, no matter what the official warranty is.
There are really own two certs I respect: Cisco's CCIE and Oracle's OCM. Both require hands-on lab demonstrations of skill.
As someone who has interviewed over a hundred network engineers for a major tech company, let me just say that experienced candidates with CCIEs and experienced candidates without CCIEs have about the same success rate of passing a technical interview. The only difference seems to be that those without lean towards practical real world experience, and those without lean towards book knowledge.
This is a complete misread of telecoms terminology, they are not banning user encryption.
The actual regulation only mentions encryption ONCE, and that is in regard to signalling information.
Signalling information is not the data. I repeat, signaling information is NOT the data.
For phone calls, signalling is the bits that tell the system where the call is go to, and who from, and other "meta" information about the call. For data, signalling is the outer part of the IP packet that carries destination information.
The encrypted part of data is in the PAYLOAD. And they don't require the payload to be decrypted. It's also the same section that requires the info to not be compressed. Are they really going to decompress all files before sending them off? No way.
All they are requiring is that the phone call source/destination info, and Ip traffic packets are not encrypted *further* by the ISP. Customer VPN data will continue to flow as normal.
IAANE (I am a network engineer) and I have had to deploy a government spying^Hlegal intercept platform before, and this is pretty much just bog standard like many other countries do.
Bottom line: A non story. Pakistan wants ISPs to implement legal intercept. Big whoop, most countries have already done this.
Unlocking does NOT void a phone's warranty, as much as the manufacturers would like you to believe.
Under the relevant jurisdictions of much of/. readership, it is illegal for a manufacturer to deny a warranty claim, *unless* they can show that the modification was a factor in the fault (in this case, the third party firmware such as cyanogen).
This is what prevents car manufacturers denying warranty claims on, say a gearbox, just because you replaced the radio. Same goes for your phone, if the camera CCD starts playing up, they cannot blame the firmware and deny coverage.
My Nexus S is rather well behaved in this regard. "fastboot oem unlock" says that it *may* affect the warranty, but does not state that it is outright void.
For the US, read up on the Magnnuson Moss Warranty Act.
They'd win the Poker World Series. This is a winning hand to show, after all of the recent moves and relatively quiet action regarding the patent battles. Dont buy into the consortium, play victim and complain about others destroying android, then buy Motorola (and their 17000 patents).
The multicast address space in IPv4 is woefully small just a few/8's (each provider generally only gets an allocation of a/24 or/23). Multicast on v4 is just not feasible at internet scales.
IPv6 is much more promising however, given the vast improvement in address space. The only problem with multicast in general, is that content providers dont like the lack of control (anyone can join a multicast stream WITHOUT the provider knowing about it). Providers want total control over every client (somewhat of a common theme with modern media delivery mechanisms). Perhaps the solution, is some kind of crypto on the streams that clients must negotiate the key for via unicast before getting the stream. But then its scarily close to drm.
Either way, I'm quite excited about the possibility of v6 multicast taking off once v6 is the norm (probably not long after duke nukem forever is released).
For the same reason that any warranty-covered device loses the protection of the warranty if you change something on it - you can't guarantee that you didn't break it yourself.
Read up on the Magnuson Moss Warranty Act. This is an American law but most modern countries have laws with the same principles.
Essentially, warranties cannot be voided by modification unless the manufacturer can prove that the modification caused the fault. This is the reason why you can install after market wiper blades and other accessories on your car without voiding the warranty. It would be outrageous for a car manufacturer otherwise. They can only deny warranty repairs when your replacing of a component specifically contributed to that fault.
The same goes for phones - a manufacturer cannot deny a warranty repair on something like a loose screen or faulty button because you installed an alternative OS on it. Of course, if you install something that lets you overstress a component (eg root the phone to drive an LED flash brighter than the stock OS), then they can deny the warranty on that component. But still would have to repair a loose screen, etc.
My Nexus S phone addresses this somewhat better than most. When you go through the legitimate unlock procedure, it warns that it "might" void some warranty, rather than stating that it "will".
So yeah, please stop spreading the FUD that jailbreaking/etc will void your warranty. It will NOT automatically void your warranty, and you can legitimately argue with the manufacturer that many warranty claims are still valid.
Back in '06 (prior to the '09 filing date), this guy modded a mouse with a nokia lcd screen. I wonder how many of apple's patent claims are invalidated by this?
I came up with a different answer, based on the summary's wording.
Firstly, the sex of the second child is not determined by the first. Whatever one child is, the other will always be 50% chance of being either.
What we can deduce from the wording is that his other child is not a son born on a tuesday.
We draw a two column, 7 row matrix. The rows are days of the week, and the columns are boy/girl. Write a tick in each cell if that is a valid sex and day for the child. We are left with 14 possibilities. 7 of those are girls (a girl can be born on any day), but only 6 are boys (as according to the wording, only ONE is a son born on tuesday...if the other is a son, it cannot be a tuesday, so we are left with 6 days if it's a boy. We give that probability to the girl column.
Thus we are left with 8 out of 14 chances being a girl, and 6 out of 14 being a boy. In decimal:
What I'd like to see on Android, though, is a permission that controls whether an app is allowed to spawn background services, which would be listed alongside others in the confirmation screen when app is installed.
Whilst Android does not have this, since version 2.0 they have vastly improved background process behaviour.
Previous to 2.0, a service (ie background app) could request foreground priority, oblivious to the user. This would flag it as important enough such that it would not be killed when the system needed resources. The intention is things like music players needing to always keep playing the music.
Unfortunately human nature rolled in and every developer felt that _their_ app was the most important one on the system, so had useless crap always running (updates, lots of network polling, etc) and so with many apps installed, the system could become sluggish even if there was only one visible app in the foreground.
Since 2.0, the old system call for this (setForeground()) has been turned into a No-Op, and apps wishing to retain high priority privileges in the background are now forced to display a notification in the status bar. Result? Apps cannot quietly hog system resources, but now must inform the user, which has generally resulted in much less resource hungry apps, snappier performance, and better battery life.
Flying Sydney, Australia to California is similar. There have been numerous times when I departed Sydney after lunch on Saturday, spend 14 hours in a plane, then land at San Francisco in time for breakfast on _the same day_.
Amusing chat over IM with a friend one such day:
Them: How's your Saturday? Me: Good, had lunch in Sydney then breakfast in San Francisco after that. Them: wtf???
There are ~3500 android apps out there now, virtually every one of them written assuming HTC Dream hardware.
It will be very interesting to see how they all cope when run on emerging hardware with vastly different characteristics and screens to the opening device.
My own Android game is not exempt and will need better adaptability (yeah, hypocrite).
You can test and test all you want outside of production, and any respectable shop will have every piece of code thoroughly unit tested and will test "significant" changes against simulated (for changes that load can affect) and limited users.
But, for an environment with huge infrastructure, it becomes literally impossible to test every scenario against real user loads with real user patterns ("random" requests is not real).
When your test scripts get timeouts, they gently retry after $TIMEOUT. People arent like that. Never underestimate the power of $BIGNUM users clicking 'reload' every coupla seconds....
It's safe - all it does is run a chroot environment from your SD card, thus you are unable to break your existing system (/dev hacks aside). No kernel is booted, it lives off the running system kernel.
This means two things:
- Resources are only consumed by actual running debian processes you initiate. No mysterious background daemons. I run a bash shell, and the only extra process on the phone is one bash shell.
- Aside from memory/cpu resources (not really scarce on a 192Mb phone), zero impact on the rest of the phone (I can compile a kernel whilst making a call at the same time).
I can now install and run any debian app. With a $12 4Gb micro-sd, I can install a *lot*. Access either via keyboard or network (ssh).
python and perl on my phone - w00t!
All I'm waiting on now is someone to create python modules to interface with the phone's GUI. And/or an X server.
Slashdot Mirror
Um...you *can* install Linux on most Chromebooks. A hardware switch unlocks the bootloader to do just that.
Nope, its true. I used to work for a US owned company in Australia - because of US law, we had to do everything in accordance with Sarbanes–Oxley. It was a royal pain in the ass - 100% pure bureaucracy - and just about doubled the work required to do most of our tasks.
I'm current working for a US company in Australia, and I never have to think about SOX. We automated all of the SOX stuff into the background, so day to day I work oblivious to these things.
Didn't you have automation and process improvement to do the same?
Funny how they advertise 20 years but promise only 3.
At a $60 price tag, that doesn't boost my confidence in their product. If they are going to claim 20 years, they should have a warranty of at least between 10 and 15 years.
In many jurisdictions, you will find that statuary warranty laws mean that a lamp failing after just 3-4 years can be replaced free regardless of manufacturer warranty.
In my jurisdiction (AU) as well as others (eg EU), law mandates that a device should last as long as is reasonably expected and advertised. If they advertise it as lasting 20y but it fails after 5, they're going to find consumer agencies breathing down their backs to replace, no matter what the official warranty is.
There are really own two certs I respect: Cisco's CCIE and Oracle's OCM. Both require hands-on lab demonstrations of skill.
As someone who has interviewed over a hundred network engineers for a major tech company, let me just say that experienced candidates with CCIEs and experienced candidates without CCIEs have about the same success rate of passing a technical interview. The only difference seems to be that those without lean towards practical real world experience, and those without lean towards book knowledge.
He has recently between doing a lot of work on the interplanetary internet, you will find this is next big thing.
Does this have proper 2.5mm pin spacing throughout?
The most annoying thing about the regular arduino is the fact that you can't use standard protoboard for home made shields.
Please tell me they have fixed this problem.
http://gizmodo.com/5833654/this-5-million-piece-of-art-is-a-1-terabyte-hard-drive-filled-with-pirated-software-songs-and-more
I guess that hard drive is now worth more than the US economy.
This is a complete misread of telecoms terminology, they are not banning user encryption.
The actual regulation only mentions encryption ONCE, and that is in regard to signalling information.
Signalling information is not the data. I repeat, signaling information is NOT the data.
For phone calls, signalling is the bits that tell the system where the call is go to, and who from, and other "meta" information about the call. For data, signalling is the outer part of the IP packet that carries destination information.
The encrypted part of data is in the PAYLOAD. And they don't require the payload to be decrypted. It's also the same section that requires the
info to not be compressed. Are they really going to decompress all files before sending them off? No way.
All they are requiring is that the phone call source/destination info, and Ip traffic packets are not encrypted *further* by the ISP. Customer
VPN data will continue to flow as normal.
IAANE (I am a network engineer) and I have had to deploy a government spying^Hlegal intercept platform before, and this is pretty much just
bog standard like many other countries do.
Bottom line: A non story. Pakistan wants ISPs to implement legal intercept. Big whoop, most countries have already done this.
Unlocking does NOT void a phone's warranty, as much as the manufacturers would like you to believe.
Under the relevant jurisdictions of much of /. readership, it is illegal for a manufacturer to deny a warranty claim, *unless* they can show that the modification was a factor in the fault (in this case, the third party firmware such as cyanogen).
This is what prevents car manufacturers denying warranty claims on, say a gearbox, just because you replaced the radio. Same goes for your phone, if the camera CCD starts playing up, they cannot blame the firmware and deny coverage.
My Nexus S is rather well behaved in this regard. "fastboot oem unlock" says that it *may* affect the warranty, but does not state that it is outright void.
For the US, read up on the Magnnuson Moss Warranty Act.
They'd win the Poker World Series. This is a winning hand to show, after all of the recent moves and relatively quiet action regarding the patent battles. Dont buy into the consortium, play victim and complain about others destroying android, then buy Motorola (and their 17000 patents).
Bravo!
The multicast address space in IPv4 is woefully small just a few /8's (each provider generally only gets an allocation of a /24 or /23). Multicast on v4 is just not feasible at internet scales.
IPv6 is much more promising however, given the vast improvement in address space. The only problem with multicast in general, is that content providers dont like the lack of control (anyone can join a multicast stream WITHOUT the provider knowing about it). Providers want total control over every client (somewhat of a common theme with modern media delivery mechanisms).
Perhaps the solution, is some kind of crypto on the streams that clients must negotiate the key for via unicast before getting the stream. But then its scarily close to drm.
Either way, I'm quite excited about the possibility of v6 multicast taking off once v6 is the norm (probably not long after duke nukem forever is released).
For the same reason that any warranty-covered device loses the protection of the warranty if you change something on it - you can't guarantee that you didn't break it yourself.
Read up on the Magnuson Moss Warranty Act. This is an American law but most modern countries have laws with the same principles.
Essentially, warranties cannot be voided by modification unless the manufacturer can prove that the modification caused the fault. This is the reason why
you can install after market wiper blades and other accessories on your car without voiding the warranty. It would be outrageous for a car manufacturer
otherwise. They can only deny warranty repairs when your replacing of a component specifically contributed to that fault.
The same goes for phones - a manufacturer cannot deny a warranty repair on something like a loose screen or faulty button because you installed
an alternative OS on it. Of course, if you install something that lets you overstress a component (eg root the phone to drive an LED flash brighter than the stock OS), then they can deny the warranty on that component. But still would have to repair a loose screen, etc.
My Nexus S phone addresses this somewhat better than most. When you go through the legitimate unlock procedure, it warns that it "might" void some warranty, rather than stating that it "will".
So yeah, please stop spreading the FUD that jailbreaking/etc will void your warranty. It will NOT automatically void your warranty, and you can legitimately
argue with the manufacturer that many warranty claims are still valid.
Back in '06 (prior to the '09 filing date), this guy modded a mouse with a nokia lcd screen. I wonder how many of apple's patent claims are invalidated by this?
http://metku.net/index.html?path=mods/loginoki/index_eng
I came up with a different answer, based on the summary's wording.
Firstly, the sex of the second child is not determined by the first. Whatever one child is, the other will always be 50% chance of being either.
What we can deduce from the wording is that his other child is not a son born on a tuesday.
We draw a two column, 7 row matrix. The rows are days of the week, and the columns are boy/girl. Write a tick in each cell if that is a valid sex and day for the child. We are left with 14 possibilities. 7 of those are girls (a girl can be born on any day), but only 6 are boys (as according to the wording, only ONE is a son born on tuesday...if the other is a son, it cannot be a tuesday, so we are left with 6 days if it's a boy. We give that probability to the girl column.
Thus we are left with 8 out of 14 chances being a girl, and 6 out of 14 being a boy. In decimal:
Girl: 0.57
Boy: 0.43
QED.
What I'd like to see on Android, though, is a permission that controls whether an app is allowed to spawn background services, which would be listed alongside others in the confirmation screen when app is installed.
Whilst Android does not have this, since version 2.0 they have vastly improved background process behaviour.
Previous to 2.0, a service (ie background app) could request foreground priority, oblivious to the user. This would flag it as important enough such that it would not be killed when the system needed resources. The intention is things like music players needing to always keep playing the music.
Unfortunately human nature rolled in and every developer felt that _their_ app was the most important one on the system, so had useless crap always running (updates, lots of network polling, etc) and so with many apps installed, the system could become sluggish even if there was only one visible app in the foreground.
Since 2.0, the old system call for this (setForeground()) has been turned into a No-Op, and apps wishing to retain high priority privileges in the background are now forced to display a notification in the status bar. Result? Apps cannot quietly hog system resources, but now must inform the user, which has generally resulted in much less resource hungry apps, snappier performance, and better battery life.
Flying Sydney, Australia to California is similar. There have been numerous times when I departed Sydney after lunch on Saturday, spend 14 hours in a plane, then land at San Francisco in time for breakfast on _the same day_.
Amusing chat over IM with a friend one such day:
Them: How's your Saturday?
Me: Good, had lunch in Sydney then breakfast in San Francisco after that.
Them: wtf???
Does that mean that I could be sued for taking a shit after eating a Malay curry, on the basis that I'm making a "derivative work"?
Aren't hard disk prices always at an all time low? Have they ever gone up in price?
http://android-target.googlecode.com/ should be the correct one.
There are ~3500 android apps out there now, virtually every one of them written assuming HTC Dream hardware.
It will be very interesting to see how they all cope when run on emerging hardware with vastly different characteristics and screens to the opening device.
My own Android game is not exempt and will need better adaptability (yeah, hypocrite).
Already possible, alas you need an unlocked G1 for the tethering:
- Wifi, already there
- Sip: http://code.google.com/p/sipdroid/
- Bluetooth tether: http://code.google.com/p/android-wifi-tether/
You can test and test all you want outside of production, and any respectable shop will have every piece of code thoroughly unit tested and will test "significant" changes against simulated (for changes that load can affect) and limited users.
But, for an environment with huge infrastructure, it becomes literally impossible to test every scenario against real user loads with real user patterns ("random" requests is not real).
When your test scripts get timeouts, they gently retry after $TIMEOUT. People arent like that. Never underestimate the power of $BIGNUM users clicking 'reload' every coupla seconds....
I put debian on my Dev G1. Zero problems.
It's safe - all it does is run a chroot environment from your SD card, thus you are unable to break your existing system (/dev hacks aside). No kernel is booted, it lives off the running system kernel.
This means two things:
- Resources are only consumed by actual running debian processes you initiate. No mysterious background daemons. I run a bash shell, and the only extra process on the phone is one bash shell.
- Aside from memory/cpu resources (not really scarce on a 192Mb phone), zero impact on the rest of the phone (I can compile a kernel whilst making a call at the same time).
I can now install and run any debian app. With a $12 4Gb micro-sd, I can install a *lot*. Access either via keyboard or network (ssh).
python and perl on my phone - w00t!
All I'm waiting on now is someone to create python modules to interface with the phone's GUI. And/or an X server.
That's almost exactly how. Started at a small but growing local ISP, and worked my way up.
Also, trade conferences (geeky ones, not suity ones) are vital for getting contacts and job leads. Don't forget to attend the dinners.
A degree says you might be able to do a particular job. Experience _proves_ that you can do the job.
I never finished my degree, yet I have been able to pursue a computing career without it being a roadblock.
My present role is as an engineer at Google.