Actually, if the oil was 1-2mm thick then it wouldn't be a sheen--- it would be opaque, or at best translucent.
A "sheen" occurs when the thickness approximates the wavelengths of visible light. The sheen effect, with all its multiple colors, is the diffraction of light into its component wavelengths as the light passes through.
So a sheen is ridiculously thin---which means it takes almost no oil to create a large sheen. A single drop, for example, could probably produce a square meter of sheen (guessing, based on what I have seen happen with gasoline).
VNC is a screen-scraper, with all the issues that come with that. If that's all you have then it's at best only tolerable. The rest of the time, it's a crappy alternative. Windows Remote Desktop falls into the same category, as far as I'm concerned.
It's far better that X work the way that it does, and we use it that way. X's client-server model contributes very positively to system stability, portability, and maintainability; and when the client and server are on the same machine, as is the case with the OP, the "overhead" really isn't there at all. Any objection to X on this basis is pure and ignorant FUD.
Oh, and by the way, since X is client-server, we can move the two onto different machines. And add more machines into the mix.
You can also think of the "network transparency" part as being a side-effect of the client-server model implemented by X, which fully isolates applications from the graphics hardware. That isolation contributes in a very positive way to system stability and portability.
And, once you have a client-server model, it doesn't really matter how far apart the two are. Hence the "network transparency" part.
Regardless, anyone who argues against X because of its "network transparency" feature is arguing from a point of ignorance.
Reminder for those of you in the East Coast: Something made those Appalachian mountains. It may not be as active as the West coast, but it would be wise not to ignore it.
You go to U of Toronto or Atlanta, and let me know what luck you have getting an audience with Mr.'s Mann or Starner. Classroom, or otherwise. The good news is, when that fails you can still find good teachers elsewhere if you know where to look.
Though I'd be genuinely curious to assess Mr. Mann's and Starner's abilities to actually teach. Just because you can do the research doesn't mean you can teach the knowledge gained to someone else. And after reading some of Mr. Mann's books, he doesn't strike me as much of a teacher at all. Even after I get past the question of whether strapping off-the-shelf hardware to one's body really "paves the way" to anything as you suggest.
I'm not a retard, and don't take illegal exits or carpool lanes just because the stupid box thinks it'll get me there
Right. And if Google Maps ever paid attention to the fact that no cars were following that portion of the route, it could conceivably decide on its own that there was something WRONG with the map at that point--- and then stop recommending that route.
This is the upside of providing location data. Sadly, I don't know how to prevent the downsides.
If we could get past the obvious privacy implications, seems like Google Maps et. al could incorporate the route you ACTUALLY took into future requests for similar routes. It always irritates me when I get an obviously sub-optimal route from Google Maps, but it's never clear to me how to actually fix the problem. If Google took feedback from where I actually drove instead, over time the problem might fix itself.
It makes that possible, yes. Combine that with tools from the emdebian project, and you have one wicked embedded Linux development environment AND runtime platform. I for one am following this development closely; I have been using emdebian tools for almost two years now, having them supported in the mainline Debian installations via Multiarch is a huge step forward. Indescribably huge.
No. Your reaction illustrates that you don't understand what you are talking about.
LSB says that/lib64 is where x86_64 libraries go on x86_32 machines, but says nothing about any other machine architectures and/or combinations. The problem itself is not x86/x86_64-specific, however, so the LSB-specified solution is incomplete.
The LSB is wrong. Debian is solving the problem correctly.
The fact that "something has worked just fine for Red Hat for years now" only reflects the fact that Red Hat doesn't focus anywhere other than x86. For that and several other reasons, Red Hat is a toy operating system as far as I'm concerned.
I tried Bazaar several times, and found its performance to be lacking, to say the least. Git runs circles around Bazaar for everyday commits, branching, and merging.
And I think your complaint about git's lack of commit metadata is exceedingly theoretical. Why in the world would I want to simultaneously use two different configuration management systems on the same repository? I can't believe that need would come up except in situations where one is part-way through migration from one system to the other. And git can do that just fine.
I've yet to see a tool that can handle even a simple daily workflow
You seem to neglect the possibility that the workflow itself is broken.:)
A centralized repository is a good thing for moving code between the developers and CM teams and, ultimately, on to release. But for daily development, forcing developers to all circle around a central repository a'la svn is a huge productivity killer. Git gives you the best of both worlds here.
Some of my troubleshooting gets involved enough that I have to do local commits and branching, and stashing. I'd be considerably less productive if I had to do that in a central repository. And once I have the issue resolved, git makes it really, really easy to cherry-pick the wheat out of the chaff to push into the upstream repository.
Re:It's because
on
The Rise of Git
·
· Score: 3, Informative
I'm not aware of any _code_ sets which span 50GB, and it seems unlikely that you could get to that size without a lot of machine-generated content. Such content wouldn't be ideal for git to manage, since git depends a lot on the capabilities of diff--- and machine-generated content might not diff as effectively as human-generated code. You can hardly fault a tool for doing a poorly at a job it wasn't designed to do.
Is the content you are managing that you describe as "50GB+" actually human-generated _code_? Or is it _data_? There is a big difference to git.
On the other hand, git manages the complete Android source code. It isn't "50GB+", but it is still substantially larger than the Linux kernel--- and git does fine. However, Google breaks that code base up into 150+ sub-repositories, which is actually a quite sane thing to do. I haven't tried to place Android into a single git repository, so I can't say how well git would deal with something that large. But it wouldn't be the best way to use git, anyway.
So I think your negative review of git is uninteresting, to say the least.
The emails coming from Anonymous won't be admissible, due to chain-of-custody issues. The prosecution will just go subpoena the originals, however, which will have no chain-of-custody issues and will therefore be admissible. In fact, the prosecution will avoid any contact with the Anonymous emails whatsoever, to make sure that they don't "taint" the originals.
The release from Anonymous is irrelevant to the admissibility of the emails themselves. It's a side-show.
I totally get (and agree with) your point about the subtle prejudice in his posting, but it isn't clear to me if that was his intent.
In SciFi, humans that have been augmented with electromechanical devices tend to lose some of their "humanity", at least as a plot element. Think Darth Vader here.
Real-life "cyborgs", if you want to call them that, aim to be indistinguishable from non-augmented human beings. Think Luke Skywalker here, at least from Episode V/Empire Strikes Back onwards.
Actually, modern "cyborg" research is at a point where we can exceed the abilities of ordinary human capabilities. The reason that athletes with artificial limbs cannot compete in certain Olympic sports, for example, is because it has been proven that such limbs can give them a significant performance advantage over non-augmented humans. So before long, SciFi might have it right after all...
There are two distinct types of problems that need to be solved. The first is, how to design a robot that can understand what the patient is asking for--- and can do that. Solutions to those problems are currently external to the patient now because that's the easiest place to do the research.
The second problem is, how to figure out what the patient is asking the robot to do. Solutions to those problems are currently external to the patient now because that's the easiest place to do the research.
See a pattern developing in the above?
There are definitely researchers who are doing amazing things regarding implantable technology. But at the moment, we don't have anything that's sufficiently high in the reward category to offset the stuff in the risks category, at least for implants that serve in the problem space covered by TFA.
Put simply, we'd love to implant something--- but right now, we have nothing compelling to implant.
Actually, I'm not sure implantable is really the way to go for this, even in the long run. Consider what guys like Dr. Hugh Herr (Biomechatronics Research Group, MIT Media Lab) are doing with exoskeletons. His stuff in particular is evolving so rapidly, anything implantable would be obsolete before you could even get a surgeon's appointment to implant it. And his stuff works so well externally, it's hard to see an upside for implantation.
So if you get pedantic, sure, 'Linux' means/meant the kernel and only the kernel.
In *practice*, Linux has come to describe the distributions that all use glibc, xorg, kernel, gtk, qt, etc.
To you, maybe.:) Those of use not using Linux "on the desktop" are in many cases not using glibc, xorg, etc. etc. either. I'm thinking about embedded systems that use Linux as their kernel, and a home-grown root filesystem. The overwhelming majority of consumer and SOHO routers are constructed this way, to pick but one example.
In terms of the number of physical devices running the Linux kernel, desktop machines are a distant second to all those other devices. Even if you don't count Android platforms--- which, by definition, count as Linux kernel installations.
For me, I only care about "desktop Linux" to the extent that it helps me construct those other Linux-based systems. As such, I've been running Linux as the kernel and Debian as the OS on my production workstations for nearly a decade.
The problem is that Google has made little effort to get their changes into the kernel, and when drivers for hardware are built against their kernel they are almost completely unsalvageable and a pain in the ass to bring into the mainline.
And that's different from most other contributed drivers how, exactly?:)
there's a GNU community, an X community, a Debian community, a GCC community, an Android community
The interesting part is that if you look at how code flows between those communities, the first four benefit each other in various ways. In contrast, the Android community is entirely insular, neither aiding nor being aided by the others.
I don't think you can generally say that--- or prove it.
Part of the reason that the first four communities are so visibly benefiting each other is that those communities themselves are relatively transparent. They are also mutually-dependent on each other. Android hasn't see major uptake in the FOSS community (yet!), however, so there aren't any obvious benefits to those other communities from Android at least because the communities currently contributing the most to Android aren't themselves transparent.
Given the complexity of Android's source code, I'd say it's pretty likely that Android has provided the opportunity to identify and fix issues in GCC and GNU Make, at least. Android doesn't use X, so lack of mutual benefit shouldn't be too surprising there. And I do know of at least one Android OEM that is using Debian very, very heavily so it's reasonable to conclude that there have been Android-to-Debian improvements there too.
The kernel is not shared, it is derived and has never _really_ attempted to minimise it's changes from it's upstream so really it is an incompatible fork. So not only is Android not GNU/Linux (or X/Linux or posix/Linux or BSD/Linux) it's not even Linux.
Not quite.
It's true that the Android kernel is derived from the mainline kernel. It's also true that some of what is in the Android kernel will never be merged into the mainline kernel, although some Android kernel features, like timed-GPIO, are now part of the mainline. The differences that have remained between the two kernels over the years are likely to remain that way, for various reasons.
It is NOT true, however, that the Android kernel is an "incompatible fork" from the mainline kernel. Assuming you get the runtime library situation right, ordinary "Linux" programs will run under an Android kernel just fine. So Android is most definitely "Linux" as you define the term.
The purists will correctly argue, however, that Android is an Operating System and not a kernel at all. It's just an operating system that requires a few features not found in the mainline Linux kernels. Hence the need for an Android-associated Linux kernel.
Except that your C++ code is still executed from within the Dalvik VM.
Depends on how you define "within". True, the VM allows control to pass to the C++ code. And true, that code is running in the process context of the VM. HOWEVER, the C++ code is running directly on the CPU, just like ordinary C++ code.
The situation is not unlike a shell invoking a native program. Although the native program is running as a child process to the shell, the native program is only minimally influenced by that.
Why is it not ethical to disobey a licence you consider unethical?
Because licenses don't work that way. Assuming the terms of the license are not contrary to prevailing law, you must abide by the terms of the license if you engage it. You don't get it both ways.
What if you think that you can get the courts to favour you?
You are of course welcome to give it a shot. You are warned, however, that the GPL is a formidable opponent.
Slashdot Mirror
Actually, if the oil was 1-2mm thick then it wouldn't be a sheen--- it would be opaque, or at best translucent.
A "sheen" occurs when the thickness approximates the wavelengths of visible light. The sheen effect, with all its multiple colors, is the diffraction of light into its component wavelengths as the light passes through.
So a sheen is ridiculously thin---which means it takes almost no oil to create a large sheen. A single drop, for example, could probably produce a square meter of sheen (guessing, based on what I have seen happen with gasoline).
VNC is a screen-scraper, with all the issues that come with that. If that's all you have then it's at best only tolerable. The rest of the time, it's a crappy alternative. Windows Remote Desktop falls into the same category, as far as I'm concerned.
It's far better that X work the way that it does, and we use it that way. X's client-server model contributes very positively to system stability, portability, and maintainability; and when the client and server are on the same machine, as is the case with the OP, the "overhead" really isn't there at all. Any objection to X on this basis is pure and ignorant FUD.
Oh, and by the way, since X is client-server, we can move the two onto different machines. And add more machines into the mix.
I'm just not seeing the problem here...
You can also think of the "network transparency" part as being a side-effect of the client-server model implemented by X, which fully isolates applications from the graphics hardware. That isolation contributes in a very positive way to system stability and portability.
And, once you have a client-server model, it doesn't really matter how far apart the two are. Hence the "network transparency" part.
Regardless, anyone who argues against X because of its "network transparency" feature is arguing from a point of ignorance.
Reminder for those of you in the East Coast: Something made those Appalachian mountains. It may not be as active as the West coast, but it would be wise not to ignore it.
I thought they were just to cover up the coal?
Citations needed. I'm not disagreeing with anything you or the previous poster has stated, I would just love to read the publications myself.
You go to U of Toronto or Atlanta, and let me know what luck you have getting an audience with Mr.'s Mann or Starner. Classroom, or otherwise. The good news is, when that fails you can still find good teachers elsewhere if you know where to look.
Though I'd be genuinely curious to assess Mr. Mann's and Starner's abilities to actually teach. Just because you can do the research doesn't mean you can teach the knowledge gained to someone else. And after reading some of Mr. Mann's books, he doesn't strike me as much of a teacher at all. Even after I get past the question of whether strapping off-the-shelf hardware to one's body really "paves the way" to anything as you suggest.
I'm not a retard, and don't take illegal exits or carpool lanes just because the stupid box thinks it'll get me there
Right. And if Google Maps ever paid attention to the fact that no cars were following that portion of the route, it could conceivably decide on its own that there was something WRONG with the map at that point--- and then stop recommending that route.
This is the upside of providing location data. Sadly, I don't know how to prevent the downsides.
If we could get past the obvious privacy implications, seems like Google Maps et. al could incorporate the route you ACTUALLY took into future requests for similar routes. It always irritates me when I get an obviously sub-optimal route from Google Maps, but it's never clear to me how to actually fix the problem. If Google took feedback from where I actually drove instead, over time the problem might fix itself.
It makes that possible, yes. Combine that with tools from the emdebian project, and you have one wicked embedded Linux development environment AND runtime platform. I for one am following this development closely; I have been using emdebian tools for almost two years now, having them supported in the mainline Debian installations via Multiarch is a huge step forward. Indescribably huge.
It generalizes to cases larger than 64-bit vs. 32-bit. Big-endian vs. little-endian, hardware FPU vs. software FPU emulation, etc.
No. Your reaction illustrates that you don't understand what you are talking about.
LSB says that /lib64 is where x86_64 libraries go on x86_32 machines, but says nothing about any other machine architectures and/or combinations. The problem itself is not x86/x86_64-specific, however, so the LSB-specified solution is incomplete.
The LSB is wrong. Debian is solving the problem correctly.
The fact that "something has worked just fine for Red Hat for years now" only reflects the fact that Red Hat doesn't focus anywhere other than x86. For that and several other reasons, Red Hat is a toy operating system as far as I'm concerned.
I tried Bazaar several times, and found its performance to be lacking, to say the least. Git runs circles around Bazaar for everyday commits, branching, and merging.
And I think your complaint about git's lack of commit metadata is exceedingly theoretical. Why in the world would I want to simultaneously use two different configuration management systems on the same repository? I can't believe that need would come up except in situations where one is part-way through migration from one system to the other. And git can do that just fine.
I've yet to see a tool that can handle even a simple daily workflow
You seem to neglect the possibility that the workflow itself is broken. :)
A centralized repository is a good thing for moving code between the developers and CM teams and, ultimately, on to release. But for daily development, forcing developers to all circle around a central repository a'la svn is a huge productivity killer. Git gives you the best of both worlds here.
Some of my troubleshooting gets involved enough that I have to do local commits and branching, and stashing. I'd be considerably less productive if I had to do that in a central repository. And once I have the issue resolved, git makes it really, really easy to cherry-pick the wheat out of the chaff to push into the upstream repository.
I'm not aware of any _code_ sets which span 50GB, and it seems unlikely that you could get to that size without a lot of machine-generated content. Such content wouldn't be ideal for git to manage, since git depends a lot on the capabilities of diff--- and machine-generated content might not diff as effectively as human-generated code. You can hardly fault a tool for doing a poorly at a job it wasn't designed to do.
Is the content you are managing that you describe as "50GB+" actually human-generated _code_? Or is it _data_? There is a big difference to git.
On the other hand, git manages the complete Android source code. It isn't "50GB+", but it is still substantially larger than the Linux kernel--- and git does fine. However, Google breaks that code base up into 150+ sub-repositories, which is actually a quite sane thing to do. I haven't tried to place Android into a single git repository, so I can't say how well git would deal with something that large. But it wouldn't be the best way to use git, anyway.
So I think your negative review of git is uninteresting, to say the least.
The emails coming from Anonymous won't be admissible, due to chain-of-custody issues. The prosecution will just go subpoena the originals, however, which will have no chain-of-custody issues and will therefore be admissible. In fact, the prosecution will avoid any contact with the Anonymous emails whatsoever, to make sure that they don't "taint" the originals.
The release from Anonymous is irrelevant to the admissibility of the emails themselves. It's a side-show.
I sincerely hope I'm not the only one who gets this joke! :)
I totally get (and agree with) your point about the subtle prejudice in his posting, but it isn't clear to me if that was his intent.
In SciFi, humans that have been augmented with electromechanical devices tend to lose some of their "humanity", at least as a plot element. Think Darth Vader here.
Real-life "cyborgs", if you want to call them that, aim to be indistinguishable from non-augmented human beings. Think Luke Skywalker here, at least from Episode V/Empire Strikes Back onwards.
Actually, modern "cyborg" research is at a point where we can exceed the abilities of ordinary human capabilities. The reason that athletes with artificial limbs cannot compete in certain Olympic sports, for example, is because it has been proven that such limbs can give them a significant performance advantage over non-augmented humans. So before long, SciFi might have it right after all...
There are two distinct types of problems that need to be solved. The first is, how to design a robot that can understand what the patient is asking for--- and can do that. Solutions to those problems are currently external to the patient now because that's the easiest place to do the research.
The second problem is, how to figure out what the patient is asking the robot to do. Solutions to those problems are currently external to the patient now because that's the easiest place to do the research.
See a pattern developing in the above?
There are definitely researchers who are doing amazing things regarding implantable technology. But at the moment, we don't have anything that's sufficiently high in the reward category to offset the stuff in the risks category, at least for implants that serve in the problem space covered by TFA.
Put simply, we'd love to implant something--- but right now, we have nothing compelling to implant.
Actually, I'm not sure implantable is really the way to go for this, even in the long run. Consider what guys like Dr. Hugh Herr (Biomechatronics Research Group, MIT Media Lab) are doing with exoskeletons. His stuff in particular is evolving so rapidly, anything implantable would be obsolete before you could even get a surgeon's appointment to implant it. And his stuff works so well externally, it's hard to see an upside for implantation.
So if you get pedantic, sure, 'Linux' means/meant the kernel and only the kernel.
In *practice*, Linux has come to describe the distributions that all use glibc, xorg, kernel, gtk, qt, etc.
To you, maybe. :) Those of use not using Linux "on the desktop" are in many cases not using glibc, xorg, etc. etc. either. I'm thinking about embedded systems that use Linux as their kernel, and a home-grown root filesystem. The overwhelming majority of consumer and SOHO routers are constructed this way, to pick but one example.
In terms of the number of physical devices running the Linux kernel, desktop machines are a distant second to all those other devices. Even if you don't count Android platforms--- which, by definition, count as Linux kernel installations.
For me, I only care about "desktop Linux" to the extent that it helps me construct those other Linux-based systems. As such, I've been running Linux as the kernel and Debian as the OS on my production workstations for nearly a decade.
The problem is that Google has made little effort to get their changes into the kernel, and when drivers for hardware are built against their kernel they are almost completely unsalvageable and a pain in the ass to bring into the mainline.
And that's different from most other contributed drivers how, exactly? :)
The interesting part is that if you look at how code flows between those communities, the first four benefit each other in various ways. In contrast, the Android community is entirely insular, neither aiding nor being aided by the others.
I don't think you can generally say that--- or prove it.
Part of the reason that the first four communities are so visibly benefiting each other is that those communities themselves are relatively transparent. They are also mutually-dependent on each other. Android hasn't see major uptake in the FOSS community (yet!), however, so there aren't any obvious benefits to those other communities from Android at least because the communities currently contributing the most to Android aren't themselves transparent.
Given the complexity of Android's source code, I'd say it's pretty likely that Android has provided the opportunity to identify and fix issues in GCC and GNU Make, at least. Android doesn't use X, so lack of mutual benefit shouldn't be too surprising there. And I do know of at least one Android OEM that is using Debian very, very heavily so it's reasonable to conclude that there have been Android-to-Debian improvements there too.
The kernel is not shared, it is derived and has never _really_ attempted to minimise it's changes from it's upstream so really it is an incompatible fork. So not only is Android not GNU/Linux (or X/Linux or posix/Linux or BSD/Linux) it's not even Linux.
Not quite.
It's true that the Android kernel is derived from the mainline kernel. It's also true that some of what is in the Android kernel will never be merged into the mainline kernel, although some Android kernel features, like timed-GPIO, are now part of the mainline. The differences that have remained between the two kernels over the years are likely to remain that way, for various reasons.
It is NOT true, however, that the Android kernel is an "incompatible fork" from the mainline kernel. Assuming you get the runtime library situation right, ordinary "Linux" programs will run under an Android kernel just fine. So Android is most definitely "Linux" as you define the term.
The purists will correctly argue, however, that Android is an Operating System and not a kernel at all. It's just an operating system that requires a few features not found in the mainline Linux kernels. Hence the need for an Android-associated Linux kernel.
Except that your C++ code is still executed from within the Dalvik VM.
Depends on how you define "within". True, the VM allows control to pass to the C++ code. And true, that code is running in the process context of the VM. HOWEVER, the C++ code is running directly on the CPU, just like ordinary C++ code.
The situation is not unlike a shell invoking a native program. Although the native program is running as a child process to the shell, the native program is only minimally influenced by that.
Redistributing a Copyrighted work is a federal offense in the USA and many other places.
See also the Berne Convention. The concept of Copyright has teeth worldwide.
Why is it not ethical to disobey a licence you consider unethical?
Because licenses don't work that way. Assuming the terms of the license are not contrary to prevailing law, you must abide by the terms of the license if you engage it. You don't get it both ways.
What if you think that you can get the courts to favour you?
You are of course welcome to give it a shot. You are warned, however, that the GPL is a formidable opponent.