Cygwin tries to emulate Unix semantics in userspace, layering POSIX on top of Win32. It doesn't work very well, and has perf issues, because the two don't match. E.g. implementing fork() that way is complicated.
And yes, Cygwin requires binaries to be recompiled. This does not.
This is more like WINE in that it loads ELF binaries directly. But it is unlike WINE and Cygwin in that it doesn't try to emulate the userspace API (i.e. POSIX). Instead, it emulates syscalls - the interface between userspace (e.g. glibc) and the kernel. Consequently, because the translation happens on a much lower level, and all code higher than that is reused directly, there's less to break due to emulating incorrectly. And because it runs directly on top of NT rather than Win32 subsystem, it can implement POSIX semantics without jumping through Win32 hoops, and have it all be very fast.
The thing that's most similar to this is Linux binaries support in FreeBSD.
There's no reason why the same thing can't be done to any other distro. All this does is replace the kernel, userspace remains the same, essentially. So if you wanted to run Slackware or Arch, it should be entirely possible.
Linux user space stuff. This is an emulation layer for Linux userspace-to-kernelspace, substituting the later part. So everything in Ubuntu and Debian archives that doesn't need direct hardware access (e.g. X) should run just fine. And you can probably combine it with some existing Win32 X implementations to get a full-fledged GUI, too.
I do know about it. I also know that it's a defense, not a license. You can still be sued, and you could still be on the hook for legal expenses. It's enough to create a substantial chill, especially for open source.
Everything that I said above was about copying (i.e. reimplementing) an API. That should not fall under copyright, ever. Otherwise, interoperability is dead.
It was not an argument, merely a point. And it's as subtle as the situation requires, which is to say, not at all.
The notion that APIs are copyrightable is bullshit, because APIs describe what is done, not how it is done. It is unfortunate that we have courts in this country that are unable to comprehend that simple fact, and everyone in the industry should make every effort to counter that - because copyrightable APIs represent a major threat to innovation and interoperability for all of us.
What is the license for ISO C APIs? I don't recall any special verbiage to that effect in the Standard, and by itself that document is copyrighted by ISO. What if they decide to enforce that copyright against implementations? What if ECMA does the same for JavaScript?
Even if it was that approach that broke it, it doesn't indicate that iPhone is secure by itself. It only indicates that a 4-digit PIN is not secure when it can be bruteforced, but we knew that already, anyway. And everyone who understands how software and hardware works knows that everything can be bruteforced with sufficient time and money. The only foolproof protection against bruteforce is a key that's long enough.
The wipeout doesn't wipe the entire device memory - it would be too slow. Instead, it wipes the key that encrypts that memory (one of the keys, present there for that explicit purpose - there is also the actual key that is derived from the PIN, so knowing that one key doesn't let you decrypt), rendering it a meaningless soup of bits. This is fairly standard approach in secure storage systems.
Now, said key is stored in flash memory. And it so happens that on this iPhone model, that flash memory is accessible if you're willing to tinker with hardware. It's possible to separate the memory chip from the rest of the phone, read the data, and copy it. Then, you can restore the key every time the device wipes itself, since the wipe only affects the memory which you have copied.
You still have to bruteforce the PIN/password to get the main encryption key, though. Which is is pretty easy if it's a 4-digit pin, but essentially impossible with a sufficiently long password.
The lesson of the story is that no system is secure against bruteforcing, and so if you want real security, you have to choose your secrets (passwords, keys etc) with the assumption that a bruteforce attack will be attempted, and all countermeasures will fail. Your actual password has to be long enough to thwart bruteforcing.
A way to unlock the phone was described in detail long before: basically, copy the flash memory that contains the "wipe key", and restore it every time the phone "wipes" itself during bruteforcing. Given that this method is known, why is it surprising that FBI unlocked the phone? The only surprising thing here is why it took them so long to actually do that, but it's only surprising if you assume that the goal of that whole kerfluffle was to unlock the phone, and not to set the precedent to force everyone to give them the skeleton key. If it's actually the latter, then it's only logical that they gave up and just unlocked it when they realized that courts won't rule in their favor.
In US, this is not at all a given. In fact, this is exactly what this case is all about - and so far the courts have favored the notion that APIs are copyrightable, unfortunately.
There are a far far larger number of male programmers so they are statistically far more likely to be qualified for those positions.
This would only be the case if 1) male programmers are more qualified than female ones on average, and 2) the study didn't account for qualification. But they claim that they did the latter, so...
I think the point that he's making is that if something requires 10x people for the same output, then the process is obviously less efficient. Generally speaking, better tech requires fewer man-hours, and it's supposed to be a good thing (it brings us one step closer to that utopian future where everything is automated, and humans don't need to work).
Slashdot Mirror
Cygwin tries to emulate Unix semantics in userspace, layering POSIX on top of Win32. It doesn't work very well, and has perf issues, because the two don't match. E.g. implementing fork() that way is complicated.
And yes, Cygwin requires binaries to be recompiled. This does not.
This is more like WINE in that it loads ELF binaries directly. But it is unlike WINE and Cygwin in that it doesn't try to emulate the userspace API (i.e. POSIX). Instead, it emulates syscalls - the interface between userspace (e.g. glibc) and the kernel. Consequently, because the translation happens on a much lower level, and all code higher than that is reused directly, there's less to break due to emulating incorrectly. And because it runs directly on top of NT rather than Win32 subsystem, it can implement POSIX semantics without jumping through Win32 hoops, and have it all be very fast.
The thing that's most similar to this is Linux binaries support in FreeBSD.
It's everything that is in Ubuntu, minus the Linux kernel.
Canonical was involved. This explains what exactly it does:
http://blog.dustinkirkland.com...
Note the name: "Windows Subsystem for Linux"
Because you prefer Windows overall for a multitude of reasons, but also want some of the conveniences of Linux command line?
Because there's that one killer app that Linux has that you want to use?
Because you are developing a cross-platform app that needs to run on both Windows and Linux, and want to test and debug it easily?
Here is a better - somewhat more technical - write-up from Ubuntu folks.
If this allows me to open up a cmd.exe and ssh to systems right off the bat, I'm scrapping the macbook and getting a surface pro.
Yes, it does exactly that.
There's no reason why the same thing can't be done to any other distro. All this does is replace the kernel, userspace remains the same, essentially. So if you wanted to run Slackware or Arch, it should be entirely possible.
It's ABI-compatible with Linux on syscall level.
Linux user space stuff. This is an emulation layer for Linux userspace-to-kernelspace, substituting the later part. So everything in Ubuntu and Debian archives that doesn't need direct hardware access (e.g. X) should run just fine. And you can probably combine it with some existing Win32 X implementations to get a full-fledged GUI, too.
Based on what I've seen so far, it's basically a Linux syscall emulation layer + ELF loader. So kernel is emulated, but userspace is entirely native.
Filesystem is mapped both ways (Windows sees Linux root as a folder, Linux sees Windows drive letters under /mnt).
Qt, for example. Python standard library.
I do know about it. I also know that it's a defense, not a license. You can still be sued, and you could still be on the hook for legal expenses. It's enough to create a substantial chill, especially for open source.
Everything that I said above was about copying (i.e. reimplementing) an API. That should not fall under copyright, ever. Otherwise, interoperability is dead.
It was not an argument, merely a point. And it's as subtle as the situation requires, which is to say, not at all.
The notion that APIs are copyrightable is bullshit, because APIs describe what is done, not how it is done. It is unfortunate that we have courts in this country that are unable to comprehend that simple fact, and everyone in the industry should make every effort to counter that - because copyrightable APIs represent a major threat to innovation and interoperability for all of us.
What is the license for ISO C APIs? I don't recall any special verbiage to that effect in the Standard, and by itself that document is copyrighted by ISO. What if they decide to enforce that copyright against implementations? What if ECMA does the same for JavaScript?
Even if it was that approach that broke it, it doesn't indicate that iPhone is secure by itself. It only indicates that a 4-digit PIN is not secure when it can be bruteforced, but we knew that already, anyway. And everyone who understands how software and hardware works knows that everything can be bruteforced with sufficient time and money. The only foolproof protection against bruteforce is a key that's long enough.
The wipeout doesn't wipe the entire device memory - it would be too slow. Instead, it wipes the key that encrypts that memory (one of the keys, present there for that explicit purpose - there is also the actual key that is derived from the PIN, so knowing that one key doesn't let you decrypt), rendering it a meaningless soup of bits. This is fairly standard approach in secure storage systems.
Now, said key is stored in flash memory. And it so happens that on this iPhone model, that flash memory is accessible if you're willing to tinker with hardware. It's possible to separate the memory chip from the rest of the phone, read the data, and copy it. Then, you can restore the key every time the device wipes itself, since the wipe only affects the memory which you have copied.
You still have to bruteforce the PIN/password to get the main encryption key, though. Which is is pretty easy if it's a 4-digit pin, but essentially impossible with a sufficiently long password.
The lesson of the story is that no system is secure against bruteforcing, and so if you want real security, you have to choose your secrets (passwords, keys etc) with the assumption that a bruteforce attack will be attempted, and all countermeasures will fail. Your actual password has to be long enough to thwart bruteforcing.
A way to unlock the phone was described in detail long before: basically, copy the flash memory that contains the "wipe key", and restore it every time the phone "wipes" itself during bruteforcing. Given that this method is known, why is it surprising that FBI unlocked the phone? The only surprising thing here is why it took them so long to actually do that, but it's only surprising if you assume that the goal of that whole kerfluffle was to unlock the phone, and not to set the precedent to force everyone to give them the skeleton key. If it's actually the latter, then it's only logical that they gave up and just unlocked it when they realized that courts won't rule in their favor.
coming from C++ mainly forced to do MFC stuff and related stuff on Windows.
Your baseline is so bad that "particularly good" relative to that baseline is really not something to boast of.
Pretty much anything has better APIs than Java, except for JS, PHP, and possibly C++ (if you disregard Boost).
In US, this is not at all a given. In fact, this is exactly what this case is all about - and so far the courts have favored the notion that APIs are copyrightable, unfortunately.
http://readwrite.com/2015/06/2...
For this to be true, APIs must be copyrightable. Which is obvious bullshit, regardless of what the courts may say on the matter.
This is inside WA state capitol, in the main chamber, a year ago.
They've repeated it this year, too.
There are a far far larger number of male programmers so they are statistically far more likely to be qualified for those positions.
This would only be the case if 1) male programmers are more qualified than female ones on average, and 2) the study didn't account for qualification. But they claim that they did the latter, so...
So obviously, this was a shorthand way of saying: death to Jews in New York City is a good thing.
It depends on who you ask. Some said that it meant "Jews did it".
I think the point that he's making is that if something requires 10x people for the same output, then the process is obviously less efficient. Generally speaking, better tech requires fewer man-hours, and it's supposed to be a good thing (it brings us one step closer to that utopian future where everything is automated, and humans don't need to work).
If you have ever been on a software project that used iterations and milestones for planning, you've done the equivalent of a 5-year plan.