No one cares whether it's a public spec or not (it may be, I do not know). It's a OS header file. The functions have to be named the same way in order for end-user programs to be source-compatible. If you've been programming for 20 years, this shouldn't be too hard to grasp.
If SCO were allowed to claim copyright over this, then it would be simply impossible for Linux to provide a compatible libelf. This means you'd essentially prevent anyone from ever making compatible OS libraries, as they'd be infringing on the original author's copyright. That would be ridiculous. Public function names and prototypes (documented or not, standardized or not) are not considered copyrightable.
Another example: is Wine, according to you, a humongous violation of Microsoft's copyrights? After all, it implements the Windows API with identical function names and prototypes, undocumented features and all (which is nowhere near a published standard of any sort).
Of course it looks rearranged. It's a header file. Some of the ELF constants come straight from the ELF spec. The #ifndef stuff is bog standard code, there are a finite number of ways of writing that and the one presented happens to be the most common. The #include is another "duh" - of course you have to #include the right header, that doesn't mean it's copied. The header file is presumably deliberately compatible with the original, hence the function definitions are prototype-compatible (while being considerably different in style).
There is nothing indicative of code copying in that PDF. The Linux header is just about as different as it can be while remaining source-compatible, as it should be.
Every GPS unit is capable of receiving the time, including those in phones (it's part of the calculation to obtain position), and as far as I know even cellphone-based GPS receivers internally use NMEA. For precise to-the-microsecond time, though, you need one with a 1PPS output (a 1Hz squarewave that transitions precisely at each second), as the NMEA data will have some delay due to the serial protocol in use. NMEA alone will probably give you accuracy down to a few milliseconds.
GPS also provides an extremely accurate clock signal all around the world (after all, it comes from an atomic clock onboard the satellites). All you need is a GPS receiver. You can put most decent GPS modules into a "clock mode" where you lock their position on the globe and they optimize the calculations to give you the most accurate time.
That works for desktop drives and is a mechanical feature. For 2.5" drives that park away from the media, though, you need to actually kill power while the drive is running to see it in action, and it's an electrical feature that uses the stored energy of the spindle.
Hard drives tend to use the momentum stored in the spindle itself to at least park heads after a power failure (especially for laptop drives that park away from the media). This presumably works by powering the drive's rails through the motor controller's protection diodes. I'm not sure if they also use it for last-gasp writing of write-cached data, though. i guess it depends on whether the write controller can handle media that is losing speed.
MXM is already a standard, that's kind of the point. Just don't expect to see it on low-end smallish laptops, as there simply isn't enough space for the modularity.
No shields, which is why it's rather pointless. He just used the SPI interface pins connected to one of these. He even had to perform voltage level conversion.
To answer your question, you can just get any bitbanging USB JTAG interface based on the FT2232D or FT2232H chip. I own this one, which also happens to include a USB to RS232 converter channel (since the FT2232 has two comm channels). FT2232D versions are more common but are only USB full-speed. FT2232H versions can bitbang faster, as they USB High-Speed peripherals. You can use these with OpenOCD, which should work on Windows and Linux (and OSX and other OSes).
Well, technically, Arduinos are defined as whatever Smart Projects labels an Arduino (it's their trademark). However, yeah, Arduinos (in common usage) are defined more by their software rather than their hardware(in particular, a compatible bootloader that works with the Arduino development environment), because you don't really need much hardware to make a modern microcontroller run.
Which really just goes on to prove that there isn't anything special about Arduino at all. It's really just a bog-standard simple microcontroller breakout board (power regulator, serial I/O either via RS232 or USB, and pin headers for the micro pins) and a standard bootloader and development environment, using a slightly cooked version of C/C++ for programming (they just pre-include a header and tack on a standard main() before feeding it to GCC). Everything else is just positive feedback: Arduino is popular, so people use Arduino, so there's a large community of projects and examples and prewritten code, so Arduino becomes more popular.
I started off with microcontrollers using a crappy development board for PIC micros quite a few years back, and quickly outgrew it and have never really bothered with dev boards ever since. There isn't much of a point when you literally just feed the micro power and ground and it runs. I've built projects where the number of support components for the micro was literally zero (one, if you count the programming connector).
Strictly speaking, Arduinos aren't microcontrollers. They're a popular hobbyist embedded platform based around the Atmel AVR microcontroller family. Much like Dells are a particular brand of computer based around x86 architecture microprocessors.
But yes, "Arduino this", "Arduino that" gets tiring after a while. Arduinos have a huge following, but there are zillions of alternatives of all shapes and sizes (many of them better in many ways). There's nothing Arduino-specific about this hack.
I'm using a laptop, so my choice of graphics chipsets is limited (though this one does use an MXM card, so I can conceivably switch it for another card at some point in the future).
Currently, the big feature that Nvidia has that ATI open source drivers lack is hardware video decode acceleration. As far as I know, ATI hasn't released specs for that part of their chips. I enjoy being able to play 1080p H.264 videos with little CPU usage (heck, even with a reasonably modern Core 2 Duo, you just cannot play some high-bitrate videos without hardware help). Whenever this shows up in the open source drivers I'll definitely give ATI a serious chance.
I have no problem with both open and closed source softwre. I have an Nvidia graphics card and use their binblob drivers. As long as you trust the manufacturer to deliver quality drivers, there's no problem with that. The issue arises when people try to mix together open and closed software in order to reap the benefits of open source without giving anything practical in return.
In this case, Qualcomm are trying to avoid the mess of maintaining binary kernel drivers, while not actually providing an open source driver for their hardware. This shouldn't fly. They can either deal with kernel maintenance and binary modules themselves, or open their entire driver so the open source community can hack it, improve it, and get into a state where it can be merged into the kernel.
If this "open source" driver were merged into the kernel, it would still be tied to the closed source usermode binblob. That means the ioctl intervace is untouchable, which means pretty much nothing can be fixed (as far as the interface goes) without Qualcomm's cooperation. It also means that kernel developers have to trust the binblob, and the lack of specs also means that the behavior of the kernel drivers (e.g. their security) cannot be reasonably analyzed. This isn't good.
In fact, Nvidia have open sourced small portions of their drivers (the settings GUI and part of their kernel abstraction shim, at least), but they are maintaining these themselves. Really, there's no problem with partially open source drivers, you just can't expect open source developers to maintain the open source part for you.
Too bad this driver isn't open source. Sure, the kernel component might be, but as the announcement itself clearly states, kernel 3D drivers are really just resource managers. The real driver lives in userland, and that part isn't open source. Phoronix is hoping it will be, but I've seen no clear indication of that.
Don't hold your breath. Nothing says the userspace component will be open sourced. Without that, this isn't even remotely an open-source 3D graphics driver. This is just an attempt to take advantage of a mainline driver being constantly updated and maintained with the kernel, without actually releasing the source to the part that matters (the userspace part).
The only security you can possibly get from them is against eavesdropping (a fairly rare attack in practice)
Tell that to Google and their WiFi snooping. Eavesdropping is a lot more common than MITM.
As I said, browsers need to implement certificate memory. Unverified SSL cert security is almost as good as verified SSL cert security if the browser caches and warns when certificates change improperly. This works just like SSH, and prevents MITM attacks unless the attack is carried out the very first time you visit a specific site.
It changes from time to time; keys expire after a while and that is a good thing as it helps to limit other kinds of problems.
If it changes when it should (when it's about to expire), the browser informs you with a simple dialog (one click). If it changes when it shouldn't (the old cert would still be fine), you get a nasty warning. Again, you get a huge increase in security if you implement some simple memory and a bit of common sense behavior on top of it.
CA security is absolute if CAs are absolutely secure. Unfortunately, CAs aren't absolutely secure, and not everyone needs absolute security. We could use some sanity checks on top of CA security, as well as some reasonable security when CAs are not available.
If you connect to your bank through HTTP (and aren't redirected), nothing will save you from an attacker stealing your bank details unless you notice the lack of a lock icon indicating an SSL connection. This is exceedingly likely if, say, Joe Average user just types www.bank.com in his address bar and an attacker hijacks his connection and replaces the usual redirect to HTTPS with a man-in-the-middle attack on the bank.
Therefore, it makes zero sense to throw huge warnings for untrusted certs and yet do nothing for plain old unencrypted HTTP.
The only sane way to implement SSL warnings is to use memory. This gives you increased security (why did ChinaSSL suddenly start providing my bank's certificate? Right now, if that happens, you're 100% screwed) and avoids annoyances (no huge four-click warnings if you visit a site for the first time and its certificate is not verified by a CA).
Right now we're in the ridiculous situation where the least secure connection (HTTP) is given preferential treatment over the somewhat secure connection (unverified HTTPS), and yet the most secure connection (verified HTTPS) is both less secure than it could be (no sanity checks, if any CA signed it then it's good) and can be trivially downgraded to insecure HTTP, depending on the user's browsing habits.
This nonsense prevents widespread adoption of HTTPS for personal and noncritical sites. If browsers shipped with something like Certificate Patrol (tweaked for user usability instead of paranoia, avoiding dialogs during "normal" situations) and ditched the stupid warnings for untrusted SSL certificates (if they've never been seen using a trusted cert) it would go a long way towards encouraging the use of HTTPS and the Web would be a much safer place as a result.
Right now, if you go connect to www.mybank.com (which defaults to HTTP) and your connection is hijacked, unless you notice the lack of a lock icon, you're screwed. This is no worse than having an unverified SSL cert served and having the browser not display the lock icon as a result. It's definitely worse than the proper implementation, where the browser would warn you of an unencrypted connection that's usually encrypted, or having an unverified SSL connection that was previously seen as verified.
You're all wrong, encryption is NOTHING without trust! There is no point in encrypting your communication with [UNKNOWN]
Yes there is, if the chances of a third party sniffing your connection are higher than the chances of a third party breaking into your connection. Your argument only holds if you view the path between you and the server as a homogeneously insecure cloud. This isn't how real world networks work. Encryption alone does provide increased security over most networks, though it may not provide a security guarantee.
The Certificate Patrol extension for Firefox will. It'll tell you when a certificate changes and whether it should (e.g. whether it was near its expiration, and whether the issuer has changed).
It's considerably secure if your browser caches the certificate and puts up a warning if it changes. Then you need to be MITMed on your first visit for it to be effective, and then it has to keep up or you'll notice.
This is how SSH verification works, and I don't see many people getting MITMed, even if you don't usually check the fingerprints.
Unfortunately, all the browser vendors decided to implement this backwards and instead throw around ridiculously alarming warnings at the user if you dare use SSL for encryption only, and not verification.
You know, instead of the sane thing, just dropping the lock icon or otherwise indicating diminished (but not nonexistent security). Find that a non-expiring cert changes or a page with a verified SSL cert suddenly has a non-verified SSL cert? Then scare the living hell out of the user.
Don't forget Nintendo's IOS microkernel operating system (from the Wii), of unknown expansion (possibly "I/O System", but it also does security), which is presumed to have been developed by RouteFree^WBroadOn^WiGware. TLA collisions suck.
Hard drive encryption has nothing to do with public-key encryption, much less public-key encryption using smallish keys (by today's standards, 1024 is practically insecure).
Symmentric encryption keysizes are not comparable to public key encryption keysizes. 128-bit AES keys are unbreakable today, and 256-bit keys are just healthy overkill.
The bit fails while it is read from the disk, then persists in the OS cache. The end result is the same (a corrupted OS cache), but the cause is different, as the bit flipped before it ever made it to the cache.
Slashdot Mirror
No one cares whether it's a public spec or not (it may be, I do not know). It's a OS header file. The functions have to be named the same way in order for end-user programs to be source-compatible. If you've been programming for 20 years, this shouldn't be too hard to grasp.
If SCO were allowed to claim copyright over this, then it would be simply impossible for Linux to provide a compatible libelf. This means you'd essentially prevent anyone from ever making compatible OS libraries, as they'd be infringing on the original author's copyright. That would be ridiculous. Public function names and prototypes (documented or not, standardized or not) are not considered copyrightable.
Another example: is Wine, according to you, a humongous violation of Microsoft's copyrights? After all, it implements the Windows API with identical function names and prototypes, undocumented features and all (which is nowhere near a published standard of any sort).
Of course it looks rearranged. It's a header file. Some of the ELF constants come straight from the ELF spec. The #ifndef stuff is bog standard code, there are a finite number of ways of writing that and the one presented happens to be the most common. The #include is another "duh" - of course you have to #include the right header, that doesn't mean it's copied. The header file is presumably deliberately compatible with the original, hence the function definitions are prototype-compatible (while being considerably different in style).
There is nothing indicative of code copying in that PDF. The Linux header is just about as different as it can be while remaining source-compatible, as it should be.
Every GPS unit is capable of receiving the time, including those in phones (it's part of the calculation to obtain position), and as far as I know even cellphone-based GPS receivers internally use NMEA. For precise to-the-microsecond time, though, you need one with a 1PPS output (a 1Hz squarewave that transitions precisely at each second), as the NMEA data will have some delay due to the serial protocol in use. NMEA alone will probably give you accuracy down to a few milliseconds.
GPS also provides an extremely accurate clock signal all around the world (after all, it comes from an atomic clock onboard the satellites). All you need is a GPS receiver. You can put most decent GPS modules into a "clock mode" where you lock their position on the globe and they optimize the calculations to give you the most accurate time.
That works for desktop drives and is a mechanical feature. For 2.5" drives that park away from the media, though, you need to actually kill power while the drive is running to see it in action, and it's an electrical feature that uses the stored energy of the spindle.
Hard drives tend to use the momentum stored in the spindle itself to at least park heads after a power failure (especially for laptop drives that park away from the media). This presumably works by powering the drive's rails through the motor controller's protection diodes. I'm not sure if they also use it for last-gasp writing of write-cached data, though. i guess it depends on whether the write controller can handle media that is losing speed.
MXM is already a standard, that's kind of the point. Just don't expect to see it on low-end smallish laptops, as there simply isn't enough space for the modularity.
No shields, which is why it's rather pointless. He just used the SPI interface pins connected to one of these. He even had to perform voltage level conversion.
To answer your question, you can just get any bitbanging USB JTAG interface based on the FT2232D or FT2232H chip. I own this one, which also happens to include a USB to RS232 converter channel (since the FT2232 has two comm channels). FT2232D versions are more common but are only USB full-speed. FT2232H versions can bitbang faster, as they USB High-Speed peripherals. You can use these with OpenOCD, which should work on Windows and Linux (and OSX and other OSes).
Well, technically, Arduinos are defined as whatever Smart Projects labels an Arduino (it's their trademark). However, yeah, Arduinos (in common usage) are defined more by their software rather than their hardware(in particular, a compatible bootloader that works with the Arduino development environment), because you don't really need much hardware to make a modern microcontroller run.
Which really just goes on to prove that there isn't anything special about Arduino at all. It's really just a bog-standard simple microcontroller breakout board (power regulator, serial I/O either via RS232 or USB, and pin headers for the micro pins) and a standard bootloader and development environment, using a slightly cooked version of C/C++ for programming (they just pre-include a header and tack on a standard main() before feeding it to GCC). Everything else is just positive feedback: Arduino is popular, so people use Arduino, so there's a large community of projects and examples and prewritten code, so Arduino becomes more popular.
I started off with microcontrollers using a crappy development board for PIC micros quite a few years back, and quickly outgrew it and have never really bothered with dev boards ever since. There isn't much of a point when you literally just feed the micro power and ground and it runs. I've built projects where the number of support components for the micro was literally zero (one, if you count the programming connector).
Strictly speaking, Arduinos aren't microcontrollers. They're a popular hobbyist embedded platform based around the Atmel AVR microcontroller family. Much like Dells are a particular brand of computer based around x86 architecture microprocessors.
But yes, "Arduino this", "Arduino that" gets tiring after a while. Arduinos have a huge following, but there are zillions of alternatives of all shapes and sizes (many of them better in many ways). There's nothing Arduino-specific about this hack.
No, an if statement is a goto to the line after the if statement's body. Just about any compiler will (barring more aggressive optimization) compile
if(cond) { ... code ... ... more code ...
}
To:
if(!cond) goto endif; ... code ... ... more code ...
endif:
I'm using a laptop, so my choice of graphics chipsets is limited (though this one does use an MXM card, so I can conceivably switch it for another card at some point in the future).
Currently, the big feature that Nvidia has that ATI open source drivers lack is hardware video decode acceleration. As far as I know, ATI hasn't released specs for that part of their chips. I enjoy being able to play 1080p H.264 videos with little CPU usage (heck, even with a reasonably modern Core 2 Duo, you just cannot play some high-bitrate videos without hardware help). Whenever this shows up in the open source drivers I'll definitely give ATI a serious chance.
I have no problem with both open and closed source softwre. I have an Nvidia graphics card and use their binblob drivers. As long as you trust the manufacturer to deliver quality drivers, there's no problem with that. The issue arises when people try to mix together open and closed software in order to reap the benefits of open source without giving anything practical in return.
In this case, Qualcomm are trying to avoid the mess of maintaining binary kernel drivers, while not actually providing an open source driver for their hardware. This shouldn't fly. They can either deal with kernel maintenance and binary modules themselves, or open their entire driver so the open source community can hack it, improve it, and get into a state where it can be merged into the kernel.
If this "open source" driver were merged into the kernel, it would still be tied to the closed source usermode binblob. That means the ioctl intervace is untouchable, which means pretty much nothing can be fixed (as far as the interface goes) without Qualcomm's cooperation. It also means that kernel developers have to trust the binblob, and the lack of specs also means that the behavior of the kernel drivers (e.g. their security) cannot be reasonably analyzed. This isn't good.
In fact, Nvidia have open sourced small portions of their drivers (the settings GUI and part of their kernel abstraction shim, at least), but they are maintaining these themselves. Really, there's no problem with partially open source drivers, you just can't expect open source developers to maintain the open source part for you.
Too bad this driver isn't open source. Sure, the kernel component might be, but as the announcement itself clearly states, kernel 3D drivers are really just resource managers. The real driver lives in userland, and that part isn't open source. Phoronix is hoping it will be, but I've seen no clear indication of that.
Don't hold your breath. Nothing says the userspace component will be open sourced. Without that, this isn't even remotely an open-source 3D graphics driver. This is just an attempt to take advantage of a mainline driver being constantly updated and maintained with the kernel, without actually releasing the source to the part that matters (the userspace part).
I completely agree.
Tell that to Google and their WiFi snooping. Eavesdropping is a lot more common than MITM.
As I said, browsers need to implement certificate memory. Unverified SSL cert security is almost as good as verified SSL cert security if the browser caches and warns when certificates change improperly. This works just like SSH, and prevents MITM attacks unless the attack is carried out the very first time you visit a specific site.
If it changes when it should (when it's about to expire), the browser informs you with a simple dialog (one click). If it changes when it shouldn't (the old cert would still be fine), you get a nasty warning. Again, you get a huge increase in security if you implement some simple memory and a bit of common sense behavior on top of it.
CA security is absolute if CAs are absolutely secure. Unfortunately, CAs aren't absolutely secure, and not everyone needs absolute security. We could use some sanity checks on top of CA security, as well as some reasonable security when CAs are not available.
Until you get MITMed and suddenly the default HTTP connection starts working. Will you notice?
If you connect to your bank through HTTP (and aren't redirected), nothing will save you from an attacker stealing your bank details unless you notice the lack of a lock icon indicating an SSL connection. This is exceedingly likely if, say, Joe Average user just types www.bank.com in his address bar and an attacker hijacks his connection and replaces the usual redirect to HTTPS with a man-in-the-middle attack on the bank.
Therefore, it makes zero sense to throw huge warnings for untrusted certs and yet do nothing for plain old unencrypted HTTP.
The only sane way to implement SSL warnings is to use memory. This gives you increased security (why did ChinaSSL suddenly start providing my bank's certificate? Right now, if that happens, you're 100% screwed) and avoids annoyances (no huge four-click warnings if you visit a site for the first time and its certificate is not verified by a CA).
Right now we're in the ridiculous situation where the least secure connection (HTTP) is given preferential treatment over the somewhat secure connection (unverified HTTPS), and yet the most secure connection (verified HTTPS) is both less secure than it could be (no sanity checks, if any CA signed it then it's good) and can be trivially downgraded to insecure HTTP, depending on the user's browsing habits.
This nonsense prevents widespread adoption of HTTPS for personal and noncritical sites. If browsers shipped with something like Certificate Patrol (tweaked for user usability instead of paranoia, avoiding dialogs during "normal" situations) and ditched the stupid warnings for untrusted SSL certificates (if they've never been seen using a trusted cert) it would go a long way towards encouraging the use of HTTPS and the Web would be a much safer place as a result.
Right now, if you go connect to www.mybank.com (which defaults to HTTP) and your connection is hijacked, unless you notice the lack of a lock icon, you're screwed. This is no worse than having an unverified SSL cert served and having the browser not display the lock icon as a result. It's definitely worse than the proper implementation, where the browser would warn you of an unencrypted connection that's usually encrypted, or having an unverified SSL connection that was previously seen as verified.
Yes there is, if the chances of a third party sniffing your connection are higher than the chances of a third party breaking into your connection. Your argument only holds if you view the path between you and the server as a homogeneously insecure cloud. This isn't how real world networks work. Encryption alone does provide increased security over most networks, though it may not provide a security guarantee.
The Certificate Patrol extension for Firefox will. It'll tell you when a certificate changes and whether it should (e.g. whether it was near its expiration, and whether the issuer has changed).
It's considerably secure if your browser caches the certificate and puts up a warning if it changes. Then you need to be MITMed on your first visit for it to be effective, and then it has to keep up or you'll notice.
This is how SSH verification works, and I don't see many people getting MITMed, even if you don't usually check the fingerprints.
Unfortunately, all the browser vendors decided to implement this backwards and instead throw around ridiculously alarming warnings at the user if you dare use SSL for encryption only, and not verification.
You know, instead of the sane thing, just dropping the lock icon or otherwise indicating diminished (but not nonexistent security). Find that a non-expiring cert changes or a page with a verified SSL cert suddenly has a non-verified SSL cert? Then scare the living hell out of the user.
Don't forget Nintendo's IOS microkernel operating system (from the Wii), of unknown expansion (possibly "I/O System", but it also does security), which is presumed to have been developed by RouteFree^WBroadOn^WiGware. TLA collisions suck.
Hard drive encryption has nothing to do with public-key encryption, much less public-key encryption using smallish keys (by today's standards, 1024 is practically insecure).
Symmentric encryption keysizes are not comparable to public key encryption keysizes. 128-bit AES keys are unbreakable today, and 256-bit keys are just healthy overkill.
The bit fails while it is read from the disk, then persists in the OS cache. The end result is the same (a corrupted OS cache), but the cause is different, as the bit flipped before it ever made it to the cache.