Anybody ever notice the irony that conservatives keep talking about not wanting to "crush future generations with debt" when talking about the US National Debt, but are rabidly against the notion that they are actively working to crush future generations in an entirely different, but equally difficult to survive way?
Quite simply, there are two arguments:
Runaway Federal spending is creating a crushing burden for future generations.
Runaway carbon emissions is a crushing burden for future generations.
The difference: There is no consensus among economists about how burdensome the national debt really is - macroeconomics simply doesn't work the same way corporate or personal finances do. Nobel Prizes are still awarded to Keynesian economists, as well as monetarists and adherents of the Austrian school. Even though these schools of economic thought have radically different and conflicting viewpoints, each school continues to win Nobel prizes. There simply is no consensus as to how economies actually work.
On the other hand, among climate scientists, the conclusion is nearly unanimous with an overall consensus of over 98%: The climate is warming, and human burning of hydrocarbons is the cause.
The vast majority of climate deniers come from people who have no credible qualifications; a dentist shouldn't have to argue about how to pull a tooth with a businessman with a string and a door.
Yet climate scientists have to argue with crackpots with a meat thermometer and a solo cup.
... a Mach microkernel that is not related to FreeBSD in any way.
Wikipedia doesn't seem to agree:
"The BSD code present in XNU came from the FreeBSD kernel. Although much of it has been significantly modified, code sharing still occurs between Apple and the FreeBSD Project.[4]"
The XNU kernel is more of a hybrid with the FreeBSD and Mach kernels glued together.
Yup. In many ways, FreeBSD probably has more desktop users than Linux does; it's just that FreeBSD is renamed "OS X", and has a bunch of additional software dropped in. In many ways, OS X is FreeBSD with a set of additional proprietary userspace interface and API's dropped in.
And yet, in spite of OS X being a 'closed fork', Apple still voluntarily contributes a substantial amount of code back to FreeBSD. To me, it's proof that the BSD license works well, and that compulsory contribution isn't the only way to get those who improve your code to send the improvements to the community. It's also proof that "closed forks," while technically possible, are practically non-existent: Even Apple can't afford to maintain a closed fork, so they contribute code back upstream.
Sadly, there are far too many on./ that let their emotions get in the way of factual reality, and focus on what might happen, instead on what actually does happen. Much like how the MPAA worries about how DeCSS could be used to facilitate piracy, even though in most cases it's just so we can watch our own DVD's.
Apple for example is using lots of FreeBSD in their operating system, and they contribute back.
Careful, pointing out that Apple contributes back to FOSS will get you lynched on/.
Pointing out that Apple releases their OS kernel under an open license, as well as pays to develop CUPS, WebKit, and LLVM/Clang, will result in them pissing on your grave.
There really are far too many GPL extremists whom condemn any software that doesn't fit into the GPL orthodoxy, even if they use alternate free software licenses. It's almost comical how much it has in common with the Catholic persecution of the heretical Protestants - only this time, it's with a software license of all things.
The BSD and Apache licenses are good examples of non-copyleft, free licenses, and in all honesty, they don't have to worry about compelling developers to contribute their changes because of simple economics: It's prohibitively expensive to maintain a closed fork, and is almost always much cheaper to just contribute the code upstream voluntarily. It's a different mechanism than the GPL's, but it still works very well.
But most people don't have a clue about what happens inside the machine,
What do you mean most people? Virtually nobody knows what's going on inside -- and that's the problem. I can design my own voting machine from the PC board and components all the way up to software - I have the skills. Even so, there's practically nothing I know about what's going on inside.
They're black boxes with no source code, and no auditing.
Yet, any of your average electronic slot or video poker machine is required to provide source code, schematics, and has regular 100% coverage auditing.
Harder than an ATM machine? Harder than a nuclear power plant control room? Harder than a 787 Dreamliner fly by wire system?
The key problem: Price.
Your examples can be counted on to be in use pretty much all of the time.
Not so with voting machines, where they sit unused in warehouses for months on end.
As a result, it's hard to justify to "fiscally responsible" election committees that your more expensive device is the best for the job.
One of the easiest things to cheap out on is the touchscreen. The touch sensors on your iOS or Android device are generally top of the line capacitive sensors - and even they have trouble from time to time.
If you go for a cheap resistive touch sensor, you can be pretty screwed. I know my office's HP DeskJet all-in-one has an extremely low-end touch screen - it's best described as "touch the screen, and get anything except what you intended to press.
I'm far more willing to chalk it up to deprecated, cheap-ass touch sensors than I am to call it fraud.
Frankly, we need the guys designing slot machine or video poker to do our voting machines - with the same regulations too (ie. full source code disclosure, full schematics, and so on). I think it's criminal that we require casinos to prove their machines aren't hacked, and require full source code and schematics -- but the same standard doesn’t exist for voting machines.
but how much longer will it take to replace X11 on the Linux desktop? Quite a while seems likely."
Try never. Yes, I know that it should be possible to write a Wayland client that provides X11 server capability, but in that case, it is the Wayland client that is replacing X11, not Wayland.
Seriously, though, the Wayland effort appears to be throwing out every advantage the X11 display had over the Windows display for a replacement that will probably never be quite as good as a Windows. I just hope that developers of programs which currently support X11 continue to support X11, or my life will get much more difficult. In fact, for much of what I do, without X11 support (and only Wayland display supported), I would probably be better off with a Windows desktop instead of a Linux desktop.
A couple of things:
1.) Wayland isn't trying to be X. - Every 'native' Wayland program will have to be specifically compiled for Wayland. - Wayland has an in-development X11 server, where X.org uses Wayland as a frame buffer (instead of X.org providing its own). This is really more like Xquartz or any of the X11 implementations on Windows. Neither OS X nor Windows can run X11 apps natively, and neither will Wayland.
2.) Wayland's policy towards network transparency is best described in their FAQ: "that is outside the scope of Wayland." They have no intention of providing a native mechanism for network transparency in Wayland, period. The FAQ then points to the decidedly non-transparent VNC and RFB, and finally to simply bolting X11 onto Wayland. I remember a quote from a Wayland presentation with respect to network transparency: It'll be "whatever you want it to be, baby" - a rather sarcastic way of saying "because you'll have to code it yourself".
While they claim that network transparency is "orthogonal" to what Wayland is doing, I suspect that is far from the truth.
As a build master for quite a lot of software, this makes me begs the question: If I'm going to have to compile it for X11 to have network transparency to begin with, then why in the world would I even bother with Wayland? I'll just compile the apps for X11, ignore Wayland entirely. Toolkits like Qt, GTK, or wxWindows may be able to support a fallback from direct Wayland to X11... but if we're still stuck with X11, then why are we bothering with Wayland to begin with?
I don't anticipate Wayland's uptake to be swift. It's not a replacement for X, and for most early use cases, you'll have to run both Wayland and X11 just to run the apps you want to run. - The toolkits aren't ready: I don't know which version of GTK is to support Wayland, but I do know it'll be supported by Qt5, which isn't out. - After that, there'll be the massive task of re-compiling everything for both Wayland and X11, because distros have to support both use cases.
Wayland has a long road ahead - job #1 is for the toolkits to fully support it (vs. the experimental status Wayland currently has). That's going to take at least a year. Qt5, if it's anything like Qt4 (or 3, or 2...) will require application porting, which also takes time. There's the issue of getting Drivers written for Wayland - again, something that will take time.
I don't have a problem accepting the idea that a BTC can have value; I just wish its proponents would classify BTC properly.
If something of value has to be exchanged to dollars/euros/pounds), then it's not currency, but a commodity - like Oil, Gold, Silver, Wheat, etc.
At this point, Bitcoins are a bartered commodity - while there are some who will accept the barter for other goods and services, I can't use bitcoins to buy groceries using BTC any more than I can buy groceries with a bushel of wheat, or a gram of palladium.
Instead, I have to exchange the commodity for a currency, and only after that can I buy my groceries.
Even the 'bitcoin card' is just another BTC exchange.
Put another way: I could 'mine' bitcoins, or I could grow wheat in my yard. Neither are currency: In both cases, I've only collected a commodity which I must then exchange for currency. There may be a few exceptions where someone is willing to barter my wheat (or BTC) for goods/services, but by and large, all roads lead through a commodity exchange.
You know, in my state, if someone pulls stuff like that, the guy who slams on his brakes in response to a tailgater will likely get a ticket, fine, and an insurance claim -- as well as a massive number of points put against his license.
In the state's courts, juries are specifically instructed that they can assign full blame to the guy in front should they feel he is at fault - and they do, repeatedly.
The reason is because no one should have to put up with people who slam on the brakes when there is no reason; it's a public menace, and can even be elevated to a criminal charge like assault with a deadly weapon. Another little tidbit: you can't blame a sudden stop on the car; it's YOUR fault for not maintaining your car properly.
In other words: You do not have the right nor authority to attempt to force others to drive your way. If you don't like how close the guy behind you is driving, you have two options: Deal with it, or change lanes.
The problem is that to use OpenCL (or ATI's Stream SDK) to offload work from the CPU, you have to do the "xhost +" breakage, which is a serious problem for anybody who actually cares about security.
I think AMD is jumping into the arena because they feel they have to:
- NVIDIA is already making quite a splash in big data processing with their many-core GPGPU offerings - AMD already offers their FirePro line to compete with NVIDIA's Tesla and Quadro - Intel is entering the arena with their MIC/Xeon Phi product line (http://en.wikipedia.org/wiki/Intel_MIC)
AMD apparently feels they have to go down a similar path. Hopefully they will do it in a way better than is possible with their competition's offerings; NVIDIA doesn't build a full CPU on-die with their GPU, and Intel appears to have chosen not to.
Additionally, NVIDIA's and presumably Intel's many-core offerings can easily swamp the latest PCIe Gen3 bus with the number of cores they have. The total memory per core on the GPU or Phi device isn't that high, so it's very easy to become bounded by PCIe's I/O bandwidth - they have to transfer boatloads of data over the PCIe bus.
For some workloads, you can get some great performance gains; it's also important to remember that while NVIDIA (for one) likes to trumpet their 20-30x performance increase, the fact is they're cherry-picking workloads that are well-suited to their product. In my experience, it's 3-5x in the general case, because of their fundamental limitation in memory bandwidth between the PCIe card and other sources of memory - be it the "main" system memory, RDMA via InfiniBand, etc.
I'm confident AMD will design decent hardware - they might even turn a corner and make great hardware again. Without the software to drive it, however, it's a lost cause - and I have zero confidence in AMD's ability to develop that software.
NOT your $100 graphics card. I'd imagine what they are going to produce will go into server farms with custom made software.
I couldn't care less about desktop graphics; it just isn't interesting to me.
My original post was about my experiences with their $1-2k FirePro boards that compete with nVIDIA's Tesla & Quadro, to be slotted into several hundred nodes of a supercomputing cluster. If that isn't a server environment, then what is?
I hate to break it to you, but AMD's attention to software, even for a high-profile, multi-million dollar order, is laughable. Ever wonder why the Top500 has plenty of NVIDIA based supercomputers, but only one of the top 100 have AMD GPU's?
And it’s not that I hate AMD; five years ago they were fantastic. But you know what? They've had miss after miss for over half a decade, their software is horrible, and they haven't even met their own performance expectations with any product for the entire time. I really hope they can turn around, but I haven't seen any signs that they're doing it.
Didn't you know? They're open source now. Fix the problem yourself!
Sarcasm aside, I feel AMD open sourcing the drivers was more because they're throwing up their hands in surrender; they can't manage it themselves, so they're asking for outside help.
AMD also provides a library that makes it easy to write a userspace program to disable all fans and thermal throttling on the GPU - melt the thing; maybe even start a fire... useful feature, that.
The beauty is that if a user can run a GL program (or even a GPU compute job), you can fry the GPU.
To run apps that use AMD's GPU's remotely (ie. not from a local X11 session - and I mean "Local X11 session"), you have to open a security hole so big you can fit Rush Limbaugh's ego through it.
* Log into the system as root. * Add "Xhost +" to your X11 startup config (so every X session allows anybody to access it... with root permissions) * chmod ugo+rw/dev/ati/card*
I asked a group of devs from X.org how stupid it was... the short answer is "how stupid is giving root access to everybody?"
So, I asked AMD when they were planning on fixing the problem.
Short answer: Not for the foreseeable future.
I seem to recall a similar issue where CERT told users not to use AMD drivers for Windows, because it forces Windows to disable many of its security features.
I'm sensing a trend...
Do you want this kind of irresponsibility in the datacenter? EVER?
now we've got a serious editor with solid chances of taking the throne for editors.... Once it's cross-plattform that is.
Many problems here: * Textmate is Objective-C/Cocoa. The Objective-C part isn't a problem, but Cocoa is. GNUStep, while cool, doesn’t have everything Cocoa does. GNUStep isn't going to see a huge boost in developers for the sake of one text editor. * Much of what makes Textmate great is its tight integration with OS X.
Unless a legion of developers decide to jump on the GNUStep bandwagon and implement the rest of Cocoa, there's no point in starting work on porting Textmate.
Without a solid GNUStep back-end, porting Textmate would be more work than starting from scratch. And to be honest, "finishing" GNUStep would be more work than starting a new editor from scratch as well.
Google is only one of the players. Amazon is another. Throw in most major retailers, financial institutions, and so on. Next comes the data sharing between the organizations (it's only illegal if you get caught...), and you have a real problem.
Businesses shouldn't be allowed to collect data that the government can't.
Government shouldn't be allowed to collect data because "the private sector already does this."
I had the misfortune to attend a conference a few weeks ago where salesmen were being taught about "big data" by marketdroids.
These guys were drooling about wholesale intrusion into the most private aspects of our lives.
It really is the rise of big brother. The fact that it is a corporation instead of government is of little practical value; monitoring data gives those who have it power, and that power will always be abused - and will result in ruined or destroyed lives, reduced freedom, and corrupt leadership (whether government or corporate).
This raises a very good question: With it becoming easier to manufacture arbitrary goods with a general purpose 'fab-in-a-box', what kinds of goods/materials will be trivially produced at home - whether there are laws against it or not. There are even metal 3d printers, so I really don't see a limit on what can be 3D printed.
I can't help but wonder if this is yet another case of Technology rendering laws obsolete - what good is a gun control law that requires serial numbers & bans automatic weapons when you can just print your own untraceable automatic gun at home?
Banning 3D printing because it "could" be used to make illegal goods is overreaching; it's just too useful to ban because it might be used to make something illegal.
Are we seeing the last days of being able to legislate scarcity of goods?
To pick a politically hot topic: Are gun control laws about to become as obsolete as banning cryptography, where the genie is out of the bottle & can't be stuffed back in?
You apparently aren't familiar with the practice of defense in depth...
No OS is secure; not even OpenBSD, where they painstakingly audit every line of code.
Fort Knox's security isn't just because of the vaults in the gold depository - it's the army base, filled with soldiers, each of which is a layer of security (some good, some not so great), as well as an armored battalion that surrounds the depository.
Apple's sandbox is (surprise, surprise) an implementation of mandatory access control - like SELinux or AppArmor. The difference is that Apple holds the keys, because, quite honestly, nearly all users are horrible at determining what kind of permissions are 'safe' for any given program. (Just look at Android - where programs typically have to ask for access permissions, and users blindly give away far more access than is required to work).
While it's a bit of a sore point for those of us who can actually use mandatory access control, it's important to realize that MAC shouldn't be a toy that only the most skillful users can employ. This is a step that brings it to everybody.
The whole point of the article, I think, is to show that there are a lot of so-called "child-safety" locks and safes that are appallingly bad. Following a few links deeper show that it's not just the electronic lock boxes.
Trigger lock? Drop the gun on a hard surface. Lock often breaks right off.
Cable Lock? Cheap $1 tumblers, and the cable can be trivially defeated with a pair of pliers
Lock box? Well, watch the videos.
More than anything, if it can't do the job it's advertised to do, than it's a problem. The cable locks are required in many states - you'd expect the thing to do the job it was designed to do.
So more than anything, I think this is a great case of educating the customer - that if you want such a safety mechanism, there are products to avoid.
The problem is, the idea of gun locks are an abomination to many gun owners - enough that many magazines are afraid to review them to not "upset" loyal readers. So where can the good devices be found, to those interested?
A similar (commercial) concept is available on Windows, Mac, iOS, and Android: 1Password. Browser plugins are included, and it works quite well.
Sadly, there is no LInux/BSD version - but there is a browser-based '1passwordanywhere' that makes it possible to use it with any web browser - I'm not sure exactly, but I'd wager it's javascript kept in the password database.
The datastore is supposedly fully-documented - nobody has written a native Linux client yet, but one can hope...
Slashdot Mirror
Anybody ever notice the irony that conservatives keep talking about not wanting to "crush future generations with debt" when talking about the US National Debt, but are rabidly against the notion that they are actively working to crush future generations in an entirely different, but equally difficult to survive way?
Quite simply, there are two arguments:
The difference: There is no consensus among economists about how burdensome the national debt really is - macroeconomics simply doesn't work the same way corporate or personal finances do. Nobel Prizes are still awarded to Keynesian economists, as well as monetarists and adherents of the Austrian school. Even though these schools of economic thought have radically different and conflicting viewpoints, each school continues to win Nobel prizes. There simply is no consensus as to how economies actually work.
On the other hand, among climate scientists, the conclusion is nearly unanimous with an overall consensus of over 98%: The climate is warming, and human burning of hydrocarbons is the cause.
The vast majority of climate deniers come from people who have no credible qualifications; a dentist shouldn't have to argue about how to pull a tooth with a businessman with a string and a door.
Yet climate scientists have to argue with crackpots with a meat thermometer and a solo cup.
... a Mach microkernel that is not related to FreeBSD in any way.
Wikipedia doesn't seem to agree:
"The BSD code present in XNU came from the FreeBSD kernel. Although much of it has been significantly modified, code sharing still occurs between Apple and the FreeBSD Project.[4]"
The XNU kernel is more of a hybrid with the FreeBSD and Mach kernels glued together.
Yup. In many ways, FreeBSD probably has more desktop users than Linux does; it's just that FreeBSD is renamed "OS X", and has a bunch of additional software dropped in. In many ways, OS X is FreeBSD with a set of additional proprietary userspace interface and API's dropped in.
And yet, in spite of OS X being a 'closed fork', Apple still voluntarily contributes a substantial amount of code back to FreeBSD. To me, it's proof that the BSD license works well, and that compulsory contribution isn't the only way to get those who improve your code to send the improvements to the community. It's also proof that "closed forks," while technically possible, are practically non-existent: Even Apple can't afford to maintain a closed fork, so they contribute code back upstream.
Sadly, there are far too many on ./ that let their emotions get in the way of factual reality, and focus on what might happen, instead on what actually does happen. Much like how the MPAA worries about how DeCSS could be used to facilitate piracy, even though in most cases it's just so we can watch our own DVD's.
Apple for example is using lots of FreeBSD in their operating system, and they contribute back.
Careful, pointing out that Apple contributes back to FOSS will get you lynched on /.
Pointing out that Apple releases their OS kernel under an open license, as well as pays to develop CUPS, WebKit, and LLVM/Clang, will result in them pissing on your grave.
There really are far too many GPL extremists whom condemn any software that doesn't fit into the GPL orthodoxy, even if they use alternate free software licenses. It's almost comical how much it has in common with the Catholic persecution of the heretical Protestants - only this time, it's with a software license of all things.
The BSD and Apache licenses are good examples of non-copyleft, free licenses, and in all honesty, they don't have to worry about compelling developers to contribute their changes because of simple economics: It's prohibitively expensive to maintain a closed fork, and is almost always much cheaper to just contribute the code upstream voluntarily. It's a different mechanism than the GPL's, but it still works very well.
But most people don't have a clue about what happens inside the machine,
What do you mean most people? Virtually nobody knows what's going on inside -- and that's the problem. I can design my own voting machine from the PC board and components all the way up to software - I have the skills. Even so, there's practically nothing I know about what's going on inside.
They're black boxes with no source code, and no auditing.
Yet, any of your average electronic slot or video poker machine is required to provide source code, schematics, and has regular 100% coverage auditing.
Compared to no machines at all? Are you kidding?
I shudder to think of the cost and reliability to count handwritten ballots.
No, I think voting machines are here to stay; but I'm not sure that touchscreens are a better alternative to scan-tron sheets or punch cards.
Harder than an ATM machine? Harder than a nuclear power plant control room? Harder than a 787 Dreamliner fly by wire system?
The key problem: Price.
Your examples can be counted on to be in use pretty much all of the time.
Not so with voting machines, where they sit unused in warehouses for months on end.
As a result, it's hard to justify to "fiscally responsible" election committees that your more expensive device is the best for the job.
One of the easiest things to cheap out on is the touchscreen. The touch sensors on your iOS or Android device are generally top of the line capacitive sensors - and even they have trouble from time to time.
If you go for a cheap resistive touch sensor, you can be pretty screwed. I know my office's HP DeskJet all-in-one has an extremely low-end touch screen - it's best described as "touch the screen, and get anything except what you intended to press.
I'm far more willing to chalk it up to deprecated, cheap-ass touch sensors than I am to call it fraud.
Frankly, we need the guys designing slot machine or video poker to do our voting machines - with the same regulations too (ie. full source code disclosure, full schematics, and so on). I think it's criminal that we require casinos to prove their machines aren't hacked, and require full source code and schematics -- but the same standard doesn’t exist for voting machines.
Try never. Yes, I know that it should be possible to write a Wayland client that provides X11 server capability, but in that case, it is the Wayland client that is replacing X11, not Wayland.
Seriously, though, the Wayland effort appears to be throwing out every advantage the X11 display had over the Windows display for a replacement that will probably never be quite as good as a Windows. I just hope that developers of programs which currently support X11 continue to support X11, or my life will get much more difficult. In fact, for much of what I do, without X11 support (and only Wayland display supported), I would probably be better off with a Windows desktop instead of a Linux desktop.
A couple of things:
1.) Wayland isn't trying to be X.
- Every 'native' Wayland program will have to be specifically compiled for Wayland.
- Wayland has an in-development X11 server, where X.org uses Wayland as a frame buffer (instead of X.org providing its own). This is really more like Xquartz or any of the X11 implementations on Windows. Neither OS X nor Windows can run X11 apps natively, and neither will Wayland.
2.) Wayland's policy towards network transparency is best described in their FAQ: "that is outside the scope of Wayland." They have no intention of providing a native mechanism for network transparency in Wayland, period. The FAQ then points to the decidedly non-transparent VNC and RFB, and finally to simply bolting X11 onto Wayland. I remember a quote from a Wayland presentation with respect to network transparency: It'll be "whatever you want it to be, baby" - a rather sarcastic way of saying "because you'll have to code it yourself".
While they claim that network transparency is "orthogonal" to what Wayland is doing, I suspect that is far from the truth.
As a build master for quite a lot of software, this makes me begs the question: If I'm going to have to compile it for X11 to have network transparency to begin with, then why in the world would I even bother with Wayland? I'll just compile the apps for X11, ignore Wayland entirely. Toolkits like Qt, GTK, or wxWindows may be able to support a fallback from direct Wayland to X11... but if we're still stuck with X11, then why are we bothering with Wayland to begin with?
I don't anticipate Wayland's uptake to be swift. It's not a replacement for X, and for most early use cases, you'll have to run both Wayland and X11 just to run the apps you want to run.
- The toolkits aren't ready: I don't know which version of GTK is to support Wayland, but I do know it'll be supported by Qt5, which isn't out.
- After that, there'll be the massive task of re-compiling everything for both Wayland and X11, because distros have to support both use cases.
Wayland has a long road ahead - job #1 is for the toolkits to fully support it (vs. the experimental status Wayland currently has). That's going to take at least a year. Qt5, if it's anything like Qt4 (or 3, or 2...) will require application porting, which also takes time. There's the issue of getting Drivers written for Wayland - again, something that will take time.
I don't have a problem accepting the idea that a BTC can have value; I just wish its proponents would classify BTC properly.
If something of value has to be exchanged to dollars/euros/pounds), then it's not currency, but a commodity - like Oil, Gold, Silver, Wheat, etc.
At this point, Bitcoins are a bartered commodity - while there are some who will accept the barter for other goods and services, I can't use bitcoins to buy groceries using BTC any more than I can buy groceries with a bushel of wheat, or a gram of palladium.
Instead, I have to exchange the commodity for a currency, and only after that can I buy my groceries.
Even the 'bitcoin card' is just another BTC exchange.
Put another way: I could 'mine' bitcoins, or I could grow wheat in my yard. Neither are currency: In both cases, I've only collected a commodity which I must then exchange for currency. There may be a few exceptions where someone is willing to barter my wheat (or BTC) for goods/services, but by and large, all roads lead through a commodity exchange.
You know, in my state, if someone pulls stuff like that, the guy who slams on his brakes in response to a tailgater will likely get a ticket, fine, and an insurance claim -- as well as a massive number of points put against his license.
In the state's courts, juries are specifically instructed that they can assign full blame to the guy in front should they feel he is at fault - and they do, repeatedly.
The reason is because no one should have to put up with people who slam on the brakes when there is no reason; it's a public menace, and can even be elevated to a criminal charge like assault with a deadly weapon. Another little tidbit: you can't blame a sudden stop on the car; it's YOUR fault for not maintaining your car properly.
In other words: You do not have the right nor authority to attempt to force others to drive your way. If you don't like how close the guy behind you is driving, you have two options: Deal with it, or change lanes.
What is the motivation behind the ban? It doesn't make any sense to me; granted I'm just an ignorant westerner, but that's why I'm asking...
The problem is that to use OpenCL (or ATI's Stream SDK) to offload work from the CPU, you have to do the "xhost +" breakage, which is a serious problem for anybody who actually cares about security.
http://tech.slashdot.org/story/12/06/07/1653206/amdati-video-drivers-unsafe-at-any-speed
ASLR appears to be one of them, as is DEP.
I think AMD is jumping into the arena because they feel they have to:
- NVIDIA is already making quite a splash in big data processing with their many-core GPGPU offerings
- AMD already offers their FirePro line to compete with NVIDIA's Tesla and Quadro
- Intel is entering the arena with their MIC/Xeon Phi product line (http://en.wikipedia.org/wiki/Intel_MIC)
AMD apparently feels they have to go down a similar path. Hopefully they will do it in a way better than is possible with their competition's offerings; NVIDIA doesn't build a full CPU on-die with their GPU, and Intel appears to have chosen not to.
Additionally, NVIDIA's and presumably Intel's many-core offerings can easily swamp the latest PCIe Gen3 bus with the number of cores they have. The total memory per core on the GPU or Phi device isn't that high, so it's very easy to become bounded by PCIe's I/O bandwidth - they have to transfer boatloads of data over the PCIe bus.
For some workloads, you can get some great performance gains; it's also important to remember that while NVIDIA (for one) likes to trumpet their 20-30x performance increase, the fact is they're cherry-picking workloads that are well-suited to their product. In my experience, it's 3-5x in the general case, because of their fundamental limitation in memory bandwidth between the PCIe card and other sources of memory - be it the "main" system memory, RDMA via InfiniBand, etc.
I'm confident AMD will design decent hardware - they might even turn a corner and make great hardware again. Without the software to drive it, however, it's a lost cause - and I have zero confidence in AMD's ability to develop that software.
NOT your $100 graphics card. I'd imagine what they are going to produce will go into server farms with custom made software.
I couldn't care less about desktop graphics; it just isn't interesting to me.
My original post was about my experiences with their $1-2k FirePro boards that compete with nVIDIA's Tesla & Quadro, to be slotted into several hundred nodes of a supercomputing cluster. If that isn't a server environment, then what is?
I hate to break it to you, but AMD's attention to software, even for a high-profile, multi-million dollar order, is laughable. Ever wonder why the Top500 has plenty of NVIDIA based supercomputers, but only one of the top 100 have AMD GPU's?
And it’s not that I hate AMD; five years ago they were fantastic. But you know what? They've had miss after miss for over half a decade, their software is horrible, and they haven't even met their own performance expectations with any product for the entire time. I really hope they can turn around, but I haven't seen any signs that they're doing it.
Didn't you know? They're open source now. Fix the problem yourself!
Sarcasm aside, I feel AMD open sourcing the drivers was more because they're throwing up their hands in surrender; they can't manage it themselves, so they're asking for outside help.
AMD also provides a library that makes it easy to write a userspace program to disable all fans and thermal throttling on the GPU - melt the thing; maybe even start a fire... useful feature, that.
The beauty is that if a user can run a GL program (or even a GPU compute job), you can fry the GPU.
Good stuff, those AMD drivers...
There's a big problem, however: http://developer.amd.com/sdks/AMDAPPSDK/assets/App_Note-Running_AMD_APP_Apps_Remotely.pdf
To run apps that use AMD's GPU's remotely (ie. not from a local X11 session - and I mean "Local X11 session"), you have to open a security hole so big you can fit Rush Limbaugh's ego through it.
* Log into the system as root. /dev/ati/card*
* Add "Xhost +" to your X11 startup config (so every X session allows anybody to access it... with root permissions)
* chmod ugo+rw
I asked a group of devs from X.org how stupid it was... the short answer is "how stupid is giving root access to everybody?"
So, I asked AMD when they were planning on fixing the problem.
Short answer: Not for the foreseeable future.
I seem to recall a similar issue where CERT told users not to use AMD drivers for Windows, because it forces Windows to disable many of its security features.
I'm sensing a trend...
Do you want this kind of irresponsibility in the datacenter? EVER?
I can't argue with the benefits of finishing GNUstep's underlying libraries. I'd be really cool. It's also a huge job with few interested developers.
now we've got a serious editor with solid chances of taking the throne for editors. ... Once it's cross-plattform that is.
Many problems here:
* Textmate is Objective-C/Cocoa. The Objective-C part isn't a problem, but Cocoa is. GNUStep, while cool, doesn’t have everything Cocoa does. GNUStep isn't going to see a huge boost in developers for the sake of one text editor.
* Much of what makes Textmate great is its tight integration with OS X.
Unless a legion of developers decide to jump on the GNUStep bandwagon and implement the rest of Cocoa, there's no point in starting work on porting Textmate.
Without a solid GNUStep back-end, porting Textmate would be more work than starting from scratch. And to be honest, "finishing" GNUStep would be more work than starting a new editor from scratch as well.
Google is only one of the players. Amazon is another. Throw in most major retailers, financial institutions, and so on. Next comes the data sharing between the organizations (it's only illegal if you get caught...), and you have a real problem.
Businesses shouldn't be allowed to collect data that the government can't.
Government shouldn't be allowed to collect data because "the private sector already does this."
I had the misfortune to attend a conference a few weeks ago where salesmen were being taught about "big data" by marketdroids.
These guys were drooling about wholesale intrusion into the most private aspects of our lives.
It really is the rise of big brother. The fact that it is a corporation instead of government is of little practical value; monitoring data gives those who have it power, and that power will always be abused - and will result in ruined or destroyed lives, reduced freedom, and corrupt leadership (whether government or corporate).
This raises a very good question: With it becoming easier to manufacture arbitrary goods with a general purpose 'fab-in-a-box', what kinds of goods/materials will be trivially produced at home - whether there are laws against it or not. There are even metal 3d printers, so I really don't see a limit on what can be 3D printed.
I can't help but wonder if this is yet another case of Technology rendering laws obsolete - what good is a gun control law that requires serial numbers & bans automatic weapons when you can just print your own untraceable automatic gun at home?
Banning 3D printing because it "could" be used to make illegal goods is overreaching; it's just too useful to ban because it might be used to make something illegal.
Are we seeing the last days of being able to legislate scarcity of goods?
To pick a politically hot topic: Are gun control laws about to become as obsolete as banning cryptography, where the genie is out of the bottle & can't be stuffed back in?
You apparently aren't familiar with the practice of defense in depth...
No OS is secure; not even OpenBSD, where they painstakingly audit every line of code.
Fort Knox's security isn't just because of the vaults in the gold depository - it's the army base, filled with soldiers, each of which is a layer of security (some good, some not so great), as well as an armored battalion that surrounds the depository.
Apple's sandbox is (surprise, surprise) an implementation of mandatory access control - like SELinux or AppArmor. The difference is that Apple holds the keys, because, quite honestly, nearly all users are horrible at determining what kind of permissions are 'safe' for any given program. (Just look at Android - where programs typically have to ask for access permissions, and users blindly give away far more access than is required to work).
While it's a bit of a sore point for those of us who can actually use mandatory access control, it's important to realize that MAC shouldn't be a toy that only the most skillful users can employ. This is a step that brings it to everybody.
The whole point of the article, I think, is to show that there are a lot of so-called "child-safety" locks and safes that are appallingly bad. Following a few links deeper show that it's not just the electronic lock boxes.
Trigger lock? Drop the gun on a hard surface. Lock often breaks right off.
Cable Lock? Cheap $1 tumblers, and the cable can be trivially defeated with a pair of pliers
Lock box? Well, watch the videos.
More than anything, if it can't do the job it's advertised to do, than it's a problem. The cable locks are required in many states - you'd expect the thing to do the job it was designed to do.
So more than anything, I think this is a great case of educating the customer - that if you want such a safety mechanism, there are products to avoid.
The problem is, the idea of gun locks are an abomination to many gun owners - enough that many magazines are afraid to review them to not "upset" loyal readers. So where can the good devices be found, to those interested?
A similar (commercial) concept is available on Windows, Mac, iOS, and Android: 1Password. Browser plugins are included, and it works quite well.
Sadly, there is no LInux/BSD version - but there is a browser-based '1passwordanywhere' that makes it possible to use it with any web browser - I'm not sure exactly, but I'd wager it's javascript kept in the password database.
The datastore is supposedly fully-documented - nobody has written a native Linux client yet, but one can hope...