Slowly but surely make yourself familar with publications (websites) on Internet that you think you like. Find their RSS feeds and subscribe to them using your favorite RSS aggregattor application. That way you'll always have a list of what's going on, from (mostly) independent sources and without having to manually walk through a set of websites, although you can always do that too.
So, in short: websites of your liking / relevance + RSS = answer to your enquiry
Compared to the junk we constantly dump into our oceans, this space station that has done A LOT of useful research (and will do so until around 2020), most of its results not even analyzed yet, I would say, in this case, the benefit to have run ISS outweighs the unfortune of polluting the ocean with its debris.
In fact, even if we launch and deorbit a space station 10 times the size of ISS into the ocean every 20 years, it's not going to count as anything compared to the amount of junk we dump into the oceans annually.
I find it surprising that the guy behind the projects mentioned, hasn't heard or appreciated the concept called an "adapter".
An adapter is either an interface or an implementation of said interface (the term is a bit vague in that sense) designed to connect software components that can't "connect" to each other by themselves, essentially an abstraction layer. It is what you'd use if you need to extend your software, but worry about platform portability. Think of it as a LEGO brick that is needed to connect two other LEGO bricks.
I don't get all the hype with the Do-Not-Track, because from the beginning, I had zero faith in the method. Frankly, it's almost funny to read this now, when I knew this to be exactly what would happen. If not worse.
I mean, do you trust in a sign you'd put up on your front door, saying "Do not rob"? Thought so.
On Internet anno 2011, in the world we live in, with the kind of overpopulation and hunt for resources and money, the kiddie stuff that is "Do not track" does not work, at least not for your common greyzone law hustlers. The thinking needs to go in to other places, like a comfortable cookie policy that can also communicate to and from the user. So that people save some cookies they want, and reject the others. I could go on and on, but it's not really that hard, but I am surprised this "Do not track" thing has gotten so far off the ground. One would think it'd die in infancy, like all the other obviously lousier ideas.
But then, why not "glue" (as in attach with brackets and thermal paste) a heatsink with FLAT SURFACE on top of the die, and THEN "mount" the impeller on top of it - at a distance of the mentioned 1 micron, I mean?
I only proposed that because since air is one of the worst thermoconducters ever, and heatsinks and thermal paste are made for thermoconduction, principally, with the same proposed novel design the guy outperforms his own design, had it been applied directly to the CPU die, the area of which varies with CPU model etc - i.e. I am betting that with a CPU dissipating 65W like modern desktop Intel CPUs do, from an area of around 1cm2, I would guess that even with 1 micron air gap it would still be hard to dissipate the heat coming from that area, and/or require more impeller revolutions and thus contribute to more noise and earlier malfuncion / increased wear-and-tear.
Am I making sense, or have I just invented all of what I said?:)
Let's hope then that in time, users will understand that the only thing that will save them from one botnet is... another, hopefully legitimate botnet operated by the good guys.
But WHY? Why spend precios cycles that eat battery life and heat up your PC innards doing the same thing through twenty layers of twisted human logic, that a piece of native runtime plugin code can do as well? 'Plugin' is just a word, it doesn't need to be insecure, alien, buggy or . And even if they are that, the problem lies at another level.
If anything, Pdf.js will be suitable where and when energy and resource conservation isn't a factor.
As for me, I prefer to avoid all the extra layers of abstractions and have the ball fall into the same basket.
Please enlighten me, a software developer of many years, what is this gold that is Pdf.js? I mean, apart from proof-of-concept being gold in itself.
I hear your pain, but have you seen that document? No OCR in the world would be able to translate THAT into plain ascii text or something that can be identified by computers for that matter. First pages are so-so, but later on it gets really weird with text almost unreadable by even a trained eye, skewed signatures and stamps of sorts, lines upon lines, numbers at odd places on the pages etc - I guess that's the way paperwork was done in the 50s.
Of course, manual human labour - the way they do it with Re-Captchas - might get you what you need:)
I love Hemingways writings, but Hemingway aside, oh my god - an Adobe Flash application to view their files? It's slow as molasses, unresponsive, has some weird copycat of a hand cursor and has its own scrolling in addition to the page scrolling - in short, it's a disaster! Jesus, haven't these guys heard of PDF, courtesy of the same company? Or are they on LSD or something?
If it was Linux, at least you could automate such "reinstall", but with Windows, and I am saying this as a person who had to do this at least 10 times during the days I were using Windows, the software comes with their own binary installers, which are all dancing to their own tune and as a result nothing really can be automated, you have to babysit human-assisted installations. This is Photoshop, Creative Suite, most games - well, actually, pretty much EVERYTHING. Of course you can take snapshots and do change recordings and "replay" them, but the thing is that many applications break anyway when "reinstalled" that way - because more often than not, at least for the bigger vendors who can afford to spend time on such schemes, the installer generates keys for the registry which work one time only, bind to hardware configurations, time, phase of the moon and what not. In other words, replaying an installation later on results in dead software because even though it worked on your last Windows, it no longer does on your fresh setup. Most of these bummers have to do with flavors of DRM, of course.
Linux has a whole lot of its drawbacks too, but they did something right - distribution and installation of software is managed by a single known entity, that is also very automatable. In Windows, every installer is their own universe - a process that answers and bows to noone.
Oh c'mon, all hackers have some form of autism. The two go together. But just because they are autistic, doesn't mean they have no self-control, self-awareness enough to not be jailed. One thing is being an out-of-your-mind delusional serial killer with torn sense of reality and a heap of issues as a result of I dunno, destroyed childhood and systematic abuse, and another a spoiled kid knowingly hacking around. It's a safe bet he knew what he was doing, the way normal people know things, not the way autists look at paintings, books or whatever else it is they interpret completely differently.
At least, reduce his sentence, but let's plead the court does not go as far as letting him go. Maybe take away his Internets for a little while (nobody can live without Internet, it's suicide.)
1. People usually, ladies especially, carry a bag that is almost A4 dimensions, or at least A3. One can thus argue that the factor for portable computers is not width and depth but weight and height(thickness).
2. Straining your eyes to distinguish, perceive and interpret information on a smaller screen is not really fun. People prefer bigger screens, they just don't like all the extra weight and dimensions that come with it. Add to this the fact that we still don't have enough flexibility in modern operating systems to imploy the concept of angular-size for on-screen widgets, operating instead with pixels and points, and the miniature UI widgets designed for larger screens simply border on annoying for users of netbooks. A netbook with Windows 7? Hmm, would you run Windows 7 desktop on your HTC smartphone? As it is often closer to your netbook profile than your desktop or notebook is. Anything less than 12" is not a true computer for many. It's not the screen, it's the weight too. If you had a 12" in your bag that weighed 1 pound and was half an inch thick, it'd be no problem. But carrying around 3 pounds worth of 3 hours of battery life doesn't justify anything else really.
3. It is not hard to come to the conclusion that because of different factors, not the least of which is price and affordability, as the size of a notebook shrinks to that of a typical netbook, its weight, height don't shrink so much and the battery life doesn't increase by as much, but by less and less. In math terms the formula is "weight*height/battery = log(width*height)" (width and height can also correlate to screen and keyboard size.) People quickly realize that they rather spend $200 more for something that has 50% larger screen and 20% more weight, same thickness and same battery life.
4. Netbooks are too slow for the kind of software they made run. When they do run the software written for their power envelope, they run into a different problem - lack of applications. Linux didn't catch on (it has apps) because people were either scared off or because Microsoft screamed their lungs out that Windows, again, rules. They all use Windows 7 which is slow as molasses on a typical Atom netbook.
5. Same as screen, goes for keyboards. You can't shrink your fingers. And so we're back to a minimum human keyboard width - i would say Thinkpad X 12" line has as narrow keyboard as a person could comfortably use. You CAN'T make it smaller without changing the definition of what a touch keyboard is.
To sum up, people don't hate portable computers. They hate their weight, height, that the keyboard keys are too smal and too narrow, that the software is not optimized for their screens or hardware, and that they don't get as much battery as they would like. As for battery, it's a joke really - Atom CPU has around 1/4 to 1/8th of a typical Cores TDP, but because Windows is not optimized for Atom CPUs, and because they are often the LEAST POWER HUNGRY element in the entire hardware platform, the would be battery benefit is not there.
You want to revive the netbook market, shrink height and weight, make them wider for a fuller-size keyboard or drop parts of less-used qwerty layout (the Tab, Caps, L-Shift column along with tilde, F1, Esc and Fn - move them somewhere else).
Actually, a good netbook I saw recently is the Toshiba A100. The problem is it is based on NVidia Ion and to boot Linux on it you have to sit on hacker forums for 3 months straight and prey to NVidia they release another new firmware version which fixes issues you didn't know existed.
Potentially, yes. It's your typical error propagation scenario. There doesn't have to be an error in the application itself, nor will an error in application process itself crash the system, but if a path of application code - arbitrary or carefully and maliciously designed - causes a deliberate disruption of service in a component that has enough privilege to cause collateral damage in the system (a kernel mode driver for example) - even though ultimately the blame lies on that component, in practice the catalyst for the crash is your benign user-mode application. It is the detonator, if you want a car bomb analogy:) Isolation of system components to the level where the detonation described cannot occur is part of securing logical systems.
Ultimately the system is secure against the aforementioned attack if no application can indirectly corrupt system state. The important thing to consider here is also that most users don't care whether the "crash" is to be blamed on one component or the other. For them, it's the picture that matters. For the rest of us, we should blame NVidia if their driver can be compromised through its own public interface, but until it is fixed, we do a disservice to our users inviting them to use software that "detonates" said driver. One has to start from the bottom, not from the top, in my opinion. An infrastracture, a strategy has to be in place PREVENTING such chain reactions from occuring in the first place.
So, the goal is to prevent any component from corrupting global state. The devil is in the details. If you can't prevent a component from crashing itself, contain the damage. A video driver for instance is traditionally written for speed. That often causes developers to turn a blind eye on the more traditional security implications, and so the driver is released that is very fragile to unusual patterns of access. They crash it. In that case, at least contain the damage. Minix for instace will clean up as much as it can and "reload" the driver. It's all art of what is possible, but we instead hammer our way in a bit of a wrong direction. I think of our users, really. That said, I am no hater of WebGL, I just think the most dire problem with computers today is not how websites can take advantage of your GPU, it's security.
1. Trust, although essential, is not everything in security. So, to answer your question, if you trust me as much as you trust Microsoft, even though I don't think one can measure trust simply like this, I would say on the grounds where this trust can be used, you are equally secure. But like I said, besides trust there are other things that are volatile - time being one of them. Example: even though you trust Microsoft, one of the two things may happen: their site is rewritten one day with the same security certificate remaining and the new code doesn't play well with your computer and 2) software on your end is updated, the web browser for instance, and again same thing happens. I feel like you should have answered your question yourself actually.
2. I didn't say first-party is paramount to security. You did. Even though your driver is supplied by your OS vendor, does not make it automatically secure. You still have to trust it. Do you? Sufficiently you say? Well, sufficiency does not figure here. You are either secure or compromised. If you haven't been compromised yet, it's doesn't mean you won't - maybe you haven't feed the "right" sequence of calls to your driver yet:-) To answer your question: no, I wouldn't trust a website I have seen before, because of a very simple observation: websites change, while their signatures (names, certificates) remain, fooling our sense of trust. Maybe you can trust the people that built the website, but again, people come and go. Can Microsoft be trusted? I dunno, 90000 employees and all...
3. True. For the sake of the argument, some of DRI - 'drm' kernel module and another one - run in kernel space. Also, the closed source drivers run in kernel space again, as does my open-source video driver (ATI Mobile Radeon) and some others. Ideally, DRI should rule, but the diverse and thriving Linux ecosystem somehow manages to live on its own. But you are sort of right, and I do admit I was a bit too fast on the trigger. Maybe its because in general, I am a bit paranoid thinking that I have around 15Mb of binary code running in kernel space right now:/
4. There is no unknown state - the state is enforced by hardware - process removed from process stack, memory reclaimed. That is all. It's a basic principle behind process isolation on pretty much any computer platform invented in and after the 80s. I thought you knew that? Or have I misunderstood you?
5. Only if there is temperature variations between them:-) Seriously though, beautiful comparison, but I really really really don't know how to apply it to the discussion! I think my brain may explode if I attempt to.
6. Is it fair to say that it is exactly because of their security track record, that they may be expected to finally take what they have learnt the hard way and do something about it? Take Apple as an example - they have been openly advocating Mac OS as a more secure system, then someone cared enough to write a trojan and where are we now? It's the same story really, except that little brother is so proud he has gotten to the top he hasn't noticed that he was following in his big brothers footsteps.
Sure, gladly. You have half a point - indeed systems that communicate invariably affect and potentially may compromise each other. That's a fact, which can also be seen in any other field of engineering. Like they say, the only secure system is the one that is not connected [to the Internet]. But since we do connect systems, the factor here is the interface cross-section. Flash Player and Silverlight, ok I won't speak for Silverlight because I never said it is much better than WebGL, so yeah - Flash Player uses fewer and more benign interfaces than WebGL - it certainly does not execute that much GPU code, in fact most of the SWF code interpreted by it is run on your average CPU eventually, and the parts that are abstracted by Windows, again, run in USER MODE - font rendering, printer, mouse, sound etc - hence my choosing of the word "more benign". If Flash Player crashes, your OS doesn't (hopefully this includes Linux based OSes.)
Granted, Flash Player DOES now expose the GPU indirectly through its that-3d-rendering-api-codename-i-dont-remember-the-name-of, and indeed it's much of the same dilemma as with WebGL - untrusted code programming your graphic driver has the same chance of crashing your box as those fancy desktop 3d games that give you BSOD or Linux kernel panic.
To sum it all up: it's the interface cross-section that matters and the domain of the code the interfaces abstract.
I would think that with Linux kernels 13M source lines of code versus Windows 7 kernel 3M, it's more of a critique of Linux in fact. And also, out of those 13M, more are driver code lines than is the case with Windows, which thankfully heeded to years and years of operating system security research and started to finally move stuff out of the kernel into user-space with the help of their user-mode driver framework.
Conceptually, WebGL is not flawed and cannot be blamed for errors that occur outside its domain, even if these can be attributed to WebGL itself. But as part of a bigger software "ecosystem", it is to blame. You help expose seven levels of hell with the help of a ladder. A stable well-built ladder, but a ladder nevertheless. Unfortunately, system security is not like a courtroom trial - you either have it or you don't. There is no such ting as "partially secure system", when one secure part of it nevertheless cannot protect it from intruding upon the rest of it.
An essential factor in security is trust. You cannot trust a website you have never seen before to load code of its choosing to be executed on a driver supplied to you by third-party which may or may not have a stellar security record themselves. Especially when "modern" operating systems like Linux run drivers as part of their monolithic kernel and so probably WILL crash when the website code messes up the driver runtime. Windows is heading in all the right directions moving their graphics driver supporing infrastracture out of the kernel into userspace. At least that way, your entire OS won't crash bringing everything down with it. At worst, smart people will figure out doing their favourite things - injecting their code through good old buffer overflows and what not.
This is what you get when you pair three poorly isolating systems to eachother. Microsoft may have done a lot of their own mess during the years with their products' security, but for once, they are right. Not the least, becaue they probably have gotten so much flak for it they finally decided enough is enough and started going by security checklist documets and automated programs that eliminate all the obvious bugs. I sincerely hope they're getting it, for I for one am tired of hearing everyone bash them. Look into your own backyard when you get 20 million lines of code running wildly on a several hundred million computers around the globe, thanks. Or reduce your SLOC, but that, again, is another discussion.
Only dumb people refute something that is clear to anyone with half a brain functioning.
The parent provided a valid comparison of the weaknesses outlined by grandparent that are present in both BitCoin and U.S. dollar. For people who are so fond of car analogies, you fail to grasp the importance of the comparison - that at least the outlined weaknesses have nothing to do with BitCoin itself. The comparison hits the nail on the head!
If a person is wise-ass enough to have mined 500K of U.S. dollar worth of coins, then I find it appalling how they didn't think of encrypting their wallet file. I bet they didn't use CPU alone but rather a rig of expensive GPUs and optimized mining software. They are careless for not leaving the wallet on the table like that. Of all people, tinkerers and hackers ought to know how at times trivial it is to get into another system. And if the person didn't mine the 500K themselves, then the point is moot. You don't walk with 500K in cash in city suburbs - and let's face it, Internet is one large suburb. In fact it's worse - someone is constantly knocking on your door, throwing stones at your windows, calls your phones, and leaves cryptic messages to your gardener if you have one. That's an appropriate analogy of life on the Internet.
It is not BitCoins job to encrypt the wallet - the responsibility lies on a more generic level. There are plenty of files that ought to be protected from somebody already inside the system - documents and other original files like emails, IP drafts; wallets etc - all these ought to be either protected by the operating system itself or its agent(s).
First you mention how the cloud shouldn't be trusted and then ask about alternatives to DropBox?
The essence of DropBox IS cloud! WIthout the cloud, it's just a storage box (no pun intended) you connect to via a file transfer protocol variation, perhaps also on top of a shell integration of some sort. Given how you want a Linux backend, why don't you simply register with www.hetzner.de to get yourself a quad-core 8Gb RAM bare-metal Internet-connected server with plenty of hard drive space for 50â a month and do with it everything you like, including setting up that file transfer protocol of your liking so that you can store whatever you want on it, however you want. If you want the de-facto gratis option, just share the box with 50 people - paying 1â each for substantially improved privacy plus some spare generic CPU-cycles is good, no? Versus Dropbox I mean, which I agree with you kind of sucks in a way cheap chinese toys do.
That said, good luck! I know this was chosen posted here to kickstart a debate rather than fish out THE ANSWER - the question was "rhetorical":)
Slashdot Mirror
Slowly but surely make yourself familar with publications (websites) on Internet that you think you like. Find their RSS feeds and subscribe to them using your favorite RSS aggregattor application. That way you'll always have a list of what's going on, from (mostly) independent sources and without having to manually walk through a set of websites, although you can always do that too.
So, in short: websites of your liking / relevance + RSS = answer to your enquiry
Compared to the junk we constantly dump into our oceans, this space station that has done A LOT of useful research (and will do so until around 2020), most of its results not even analyzed yet, I would say, in this case, the benefit to have run ISS outweighs the unfortune of polluting the ocean with its debris.
In fact, even if we launch and deorbit a space station 10 times the size of ISS into the ocean every 20 years, it's not going to count as anything compared to the amount of junk we dump into the oceans annually.
I HATE warm laptops!
I find it surprising that the guy behind the projects mentioned, hasn't heard or appreciated the concept called an "adapter".
An adapter is either an interface or an implementation of said interface (the term is a bit vague in that sense) designed to connect software components that can't "connect" to each other by themselves, essentially an abstraction layer. It is what you'd use if you need to extend your software, but worry about platform portability. Think of it as a LEGO brick that is needed to connect two other LEGO bricks.
http://en.wikipedia.org/wiki/Adapter_pattern
I don't get all the hype with the Do-Not-Track, because from the beginning, I had zero faith in the method. Frankly, it's almost funny to read this now, when I knew this to be exactly what would happen. If not worse.
I mean, do you trust in a sign you'd put up on your front door, saying "Do not rob"? Thought so.
On Internet anno 2011, in the world we live in, with the kind of overpopulation and hunt for resources and money, the kiddie stuff that is "Do not track" does not work, at least not for your common greyzone law hustlers. The thinking needs to go in to other places, like a comfortable cookie policy that can also communicate to and from the user. So that people save some cookies they want, and reject the others. I could go on and on, but it's not really that hard, but I am surprised this "Do not track" thing has gotten so far off the ground. One would think it'd die in infancy, like all the other obviously lousier ideas.
But then, why not "glue" (as in attach with brackets and thermal paste) a heatsink with FLAT SURFACE on top of the die, and THEN "mount" the impeller on top of it - at a distance of the mentioned 1 micron, I mean?
I only proposed that because since air is one of the worst thermoconducters ever, and heatsinks and thermal paste are made for thermoconduction, principally, with the same proposed novel design the guy outperforms his own design, had it been applied directly to the CPU die, the area of which varies with CPU model etc - i.e. I am betting that with a CPU dissipating 65W like modern desktop Intel CPUs do, from an area of around 1cm2, I would guess that even with 1 micron air gap it would still be hard to dissipate the heat coming from that area, and/or require more impeller revolutions and thus contribute to more noise and earlier malfuncion / increased wear-and-tear.
Am I making sense, or have I just invented all of what I said? :)
Let's hope then that in time, users will understand that the only thing that will save them from one botnet is ... another, hopefully legitimate botnet operated by the good guys.
Begun the botnet war has.
Well written, thanks :)
But WHY? Why spend precios cycles that eat battery life and heat up your PC innards doing the same thing through twenty layers of twisted human logic, that a piece of native runtime plugin code can do as well? 'Plugin' is just a word, it doesn't need to be insecure, alien, buggy or . And even if they are that, the problem lies at another level.
If anything, Pdf.js will be suitable where and when energy and resource conservation isn't a factor.
As for me, I prefer to avoid all the extra layers of abstractions and have the ball fall into the same basket.
Please enlighten me, a software developer of many years, what is this gold that is Pdf.js? I mean, apart from proof-of-concept being gold in itself.
I hear your pain, but have you seen that document? No OCR in the world would be able to translate THAT into plain ascii text or something that can be identified by computers for that matter. First pages are so-so, but later on it gets really weird with text almost unreadable by even a trained eye, skewed signatures and stamps of sorts, lines upon lines, numbers at odd places on the pages etc - I guess that's the way paperwork was done in the 50s.
Of course, manual human labour - the way they do it with Re-Captchas - might get you what you need :)
I love Hemingways writings, but Hemingway aside, oh my god - an Adobe Flash application to view their files? It's slow as molasses, unresponsive, has some weird copycat of a hand cursor and has its own scrolling in addition to the page scrolling - in short, it's a disaster! Jesus, haven't these guys heard of PDF, courtesy of the same company? Or are they on LSD or something?
If it was Linux, at least you could automate such "reinstall", but with Windows, and I am saying this as a person who had to do this at least 10 times during the days I were using Windows, the software comes with their own binary installers, which are all dancing to their own tune and as a result nothing really can be automated, you have to babysit human-assisted installations. This is Photoshop, Creative Suite, most games - well, actually, pretty much EVERYTHING. Of course you can take snapshots and do change recordings and "replay" them, but the thing is that many applications break anyway when "reinstalled" that way - because more often than not, at least for the bigger vendors who can afford to spend time on such schemes, the installer generates keys for the registry which work one time only, bind to hardware configurations, time, phase of the moon and what not. In other words, replaying an installation later on results in dead software because even though it worked on your last Windows, it no longer does on your fresh setup. Most of these bummers have to do with flavors of DRM, of course.
Linux has a whole lot of its drawbacks too, but they did something right - distribution and installation of software is managed by a single known entity, that is also very automatable. In Windows, every installer is their own universe - a process that answers and bows to noone.
Oh c'mon, all hackers have some form of autism. The two go together. But just because they are autistic, doesn't mean they have no self-control, self-awareness enough to not be jailed. One thing is being an out-of-your-mind delusional serial killer with torn sense of reality and a heap of issues as a result of I dunno, destroyed childhood and systematic abuse, and another a spoiled kid knowingly hacking around. It's a safe bet he knew what he was doing, the way normal people know things, not the way autists look at paintings, books or whatever else it is they interpret completely differently.
At least, reduce his sentence, but let's plead the court does not go as far as letting him go. Maybe take away his Internets for a little while (nobody can live without Internet, it's suicide.)
I never believed in the idea.
1. People usually, ladies especially, carry a bag that is almost A4 dimensions, or at least A3. One can thus argue that the factor for portable computers is not width and depth but weight and height(thickness).
2. Straining your eyes to distinguish, perceive and interpret information on a smaller screen is not really fun. People prefer bigger screens, they just don't like all the extra weight and dimensions that come with it. Add to this the fact that we still don't have enough flexibility in modern operating systems to imploy the concept of angular-size for on-screen widgets, operating instead with pixels and points, and the miniature UI widgets designed for larger screens simply border on annoying for users of netbooks. A netbook with Windows 7? Hmm, would you run Windows 7 desktop on your HTC smartphone? As it is often closer to your netbook profile than your desktop or notebook is. Anything less than 12" is not a true computer for many. It's not the screen, it's the weight too. If you had a 12" in your bag that weighed 1 pound and was half an inch thick, it'd be no problem. But carrying around 3 pounds worth of 3 hours of battery life doesn't justify anything else really.
3. It is not hard to come to the conclusion that because of different factors, not the least of which is price and affordability, as the size of a notebook shrinks to that of a typical netbook, its weight, height don't shrink so much and the battery life doesn't increase by as much, but by less and less. In math terms the formula is "weight*height/battery = log(width*height)" (width and height can also correlate to screen and keyboard size.) People quickly realize that they rather spend $200 more for something that has 50% larger screen and 20% more weight, same thickness and same battery life.
4. Netbooks are too slow for the kind of software they made run. When they do run the software written for their power envelope, they run into a different problem - lack of applications. Linux didn't catch on (it has apps) because people were either scared off or because Microsoft screamed their lungs out that Windows, again, rules. They all use Windows 7 which is slow as molasses on a typical Atom netbook.
5. Same as screen, goes for keyboards. You can't shrink your fingers. And so we're back to a minimum human keyboard width - i would say Thinkpad X 12" line has as narrow keyboard as a person could comfortably use. You CAN'T make it smaller without changing the definition of what a touch keyboard is.
To sum up, people don't hate portable computers. They hate their weight, height, that the keyboard keys are too smal and too narrow, that the software is not optimized for their screens or hardware, and that they don't get as much battery as they would like. As for battery, it's a joke really - Atom CPU has around 1/4 to 1/8th of a typical Cores TDP, but because Windows is not optimized for Atom CPUs, and because they are often the LEAST POWER HUNGRY element in the entire hardware platform, the would be battery benefit is not there.
You want to revive the netbook market, shrink height and weight, make them wider for a fuller-size keyboard or drop parts of less-used qwerty layout (the Tab, Caps, L-Shift column along with tilde, F1, Esc and Fn - move them somewhere else).
Actually, a good netbook I saw recently is the Toshiba A100. The problem is it is based on NVidia Ion and to boot Linux on it you have to sit on hacker forums for 3 months straight and prey to NVidia they release another new firmware version which fixes issues you didn't know existed.
12V by 4.5A ought to be enough for everyone!
Potentially, yes. It's your typical error propagation scenario. There doesn't have to be an error in the application itself, nor will an error in application process itself crash the system, but if a path of application code - arbitrary or carefully and maliciously designed - causes a deliberate disruption of service in a component that has enough privilege to cause collateral damage in the system (a kernel mode driver for example) - even though ultimately the blame lies on that component, in practice the catalyst for the crash is your benign user-mode application. It is the detonator, if you want a car bomb analogy :) Isolation of system components to the level where the detonation described cannot occur is part of securing logical systems.
Ultimately the system is secure against the aforementioned attack if no application can indirectly corrupt system state. The important thing to consider here is also that most users don't care whether the "crash" is to be blamed on one component or the other. For them, it's the picture that matters. For the rest of us, we should blame NVidia if their driver can be compromised through its own public interface, but until it is fixed, we do a disservice to our users inviting them to use software that "detonates" said driver. One has to start from the bottom, not from the top, in my opinion. An infrastracture, a strategy has to be in place PREVENTING such chain reactions from occuring in the first place.
So, the goal is to prevent any component from corrupting global state. The devil is in the details. If you can't prevent a component from crashing itself, contain the damage. A video driver for instance is traditionally written for speed. That often causes developers to turn a blind eye on the more traditional security implications, and so the driver is released that is very fragile to unusual patterns of access. They crash it. In that case, at least contain the damage. Minix for instace will clean up as much as it can and "reload" the driver. It's all art of what is possible, but we instead hammer our way in a bit of a wrong direction. I think of our users, really. That said, I am no hater of WebGL, I just think the most dire problem with computers today is not how websites can take advantage of your GPU, it's security.
1. Trust, although essential, is not everything in security. So, to answer your question, if you trust me as much as you trust Microsoft, even though I don't think one can measure trust simply like this, I would say on the grounds where this trust can be used, you are equally secure. But like I said, besides trust there are other things that are volatile - time being one of them. Example: even though you trust Microsoft, one of the two things may happen: their site is rewritten one day with the same security certificate remaining and the new code doesn't play well with your computer and 2) software on your end is updated, the web browser for instance, and again same thing happens. I feel like you should have answered your question yourself actually.
2. I didn't say first-party is paramount to security. You did. Even though your driver is supplied by your OS vendor, does not make it automatically secure. You still have to trust it. Do you? Sufficiently you say? Well, sufficiency does not figure here. You are either secure or compromised. If you haven't been compromised yet, it's doesn't mean you won't - maybe you haven't feed the "right" sequence of calls to your driver yet :-) To answer your question: no, I wouldn't trust a website I have seen before, because of a very simple observation: websites change, while their signatures (names, certificates) remain, fooling our sense of trust. Maybe you can trust the people that built the website, but again, people come and go. Can Microsoft be trusted? I dunno, 90000 employees and all...
3. True. For the sake of the argument, some of DRI - 'drm' kernel module and another one - run in kernel space. Also, the closed source drivers run in kernel space again, as does my open-source video driver (ATI Mobile Radeon) and some others. Ideally, DRI should rule, but the diverse and thriving Linux ecosystem somehow manages to live on its own. But you are sort of right, and I do admit I was a bit too fast on the trigger. Maybe its because in general, I am a bit paranoid thinking that I have around 15Mb of binary code running in kernel space right now :/
4. There is no unknown state - the state is enforced by hardware - process removed from process stack, memory reclaimed. That is all. It's a basic principle behind process isolation on pretty much any computer platform invented in and after the 80s. I thought you knew that? Or have I misunderstood you?
5. Only if there is temperature variations between them :-) Seriously though, beautiful comparison, but I really really really don't know how to apply it to the discussion! I think my brain may explode if I attempt to.
6. Is it fair to say that it is exactly because of their security track record, that they may be expected to finally take what they have learnt the hard way and do something about it? Take Apple as an example - they have been openly advocating Mac OS as a more secure system, then someone cared enough to write a trojan and where are we now? It's the same story really, except that little brother is so proud he has gotten to the top he hasn't noticed that he was following in his big brothers footsteps.
7. Me neither.
Sure, gladly. You have half a point - indeed systems that communicate invariably affect and potentially may compromise each other. That's a fact, which can also be seen in any other field of engineering. Like they say, the only secure system is the one that is not connected [to the Internet]. But since we do connect systems, the factor here is the interface cross-section. Flash Player and Silverlight, ok I won't speak for Silverlight because I never said it is much better than WebGL, so yeah - Flash Player uses fewer and more benign interfaces than WebGL - it certainly does not execute that much GPU code, in fact most of the SWF code interpreted by it is run on your average CPU eventually, and the parts that are abstracted by Windows, again, run in USER MODE - font rendering, printer, mouse, sound etc - hence my choosing of the word "more benign". If Flash Player crashes, your OS doesn't (hopefully this includes Linux based OSes.)
Granted, Flash Player DOES now expose the GPU indirectly through its that-3d-rendering-api-codename-i-dont-remember-the-name-of, and indeed it's much of the same dilemma as with WebGL - untrusted code programming your graphic driver has the same chance of crashing your box as those fancy desktop 3d games that give you BSOD or Linux kernel panic.
To sum it all up: it's the interface cross-section that matters and the domain of the code the interfaces abstract.
I would think that with Linux kernels 13M source lines of code versus Windows 7 kernel 3M, it's more of a critique of Linux in fact. And also, out of those 13M, more are driver code lines than is the case with Windows, which thankfully heeded to years and years of operating system security research and started to finally move stuff out of the kernel into user-space with the help of their user-mode driver framework.
Conceptually, WebGL is not flawed and cannot be blamed for errors that occur outside its domain, even if these can be attributed to WebGL itself. But as part of a bigger software "ecosystem", it is to blame. You help expose seven levels of hell with the help of a ladder. A stable well-built ladder, but a ladder nevertheless. Unfortunately, system security is not like a courtroom trial - you either have it or you don't. There is no such ting as "partially secure system", when one secure part of it nevertheless cannot protect it from intruding upon the rest of it.
An essential factor in security is trust. You cannot trust a website you have never seen before to load code of its choosing to be executed on a driver supplied to you by third-party which may or may not have a stellar security record themselves. Especially when "modern" operating systems like Linux run drivers as part of their monolithic kernel and so probably WILL crash when the website code messes up the driver runtime. Windows is heading in all the right directions moving their graphics driver supporing infrastracture out of the kernel into userspace. At least that way, your entire OS won't crash bringing everything down with it. At worst, smart people will figure out doing their favourite things - injecting their code through good old buffer overflows and what not.
This is what you get when you pair three poorly isolating systems to eachother. Microsoft may have done a lot of their own mess during the years with their products' security, but for once, they are right. Not the least, becaue they probably have gotten so much flak for it they finally decided enough is enough and started going by security checklist documets and automated programs that eliminate all the obvious bugs. I sincerely hope they're getting it, for I for one am tired of hearing everyone bash them. Look into your own backyard when you get 20 million lines of code running wildly on a several hundred million computers around the globe, thanks. Or reduce your SLOC, but that, again, is another discussion.
Only dumb people refute something that is clear to anyone with half a brain functioning.
The parent provided a valid comparison of the weaknesses outlined by grandparent that are present in both BitCoin and U.S. dollar. For people who are so fond of car analogies, you fail to grasp the importance of the comparison - that at least the outlined weaknesses have nothing to do with BitCoin itself. The comparison hits the nail on the head!
If a person is wise-ass enough to have mined 500K of U.S. dollar worth of coins, then I find it appalling how they didn't think of encrypting their wallet file. I bet they didn't use CPU alone but rather a rig of expensive GPUs and optimized mining software. They are careless for not leaving the wallet on the table like that. Of all people, tinkerers and hackers ought to know how at times trivial it is to get into another system. And if the person didn't mine the 500K themselves, then the point is moot. You don't walk with 500K in cash in city suburbs - and let's face it, Internet is one large suburb. In fact it's worse - someone is constantly knocking on your door, throwing stones at your windows, calls your phones, and leaves cryptic messages to your gardener if you have one. That's an appropriate analogy of life on the Internet.
It is not BitCoins job to encrypt the wallet - the responsibility lies on a more generic level. There are plenty of files that ought to be protected from somebody already inside the system - documents and other original files like emails, IP drafts; wallets etc - all these ought to be either protected by the operating system itself or its agent(s).
First you mention how the cloud shouldn't be trusted and then ask about alternatives to DropBox?
The essence of DropBox IS cloud! WIthout the cloud, it's just a storage box (no pun intended) you connect to via a file transfer protocol variation, perhaps also on top of a shell integration of some sort. Given how you want a Linux backend, why don't you simply register with www.hetzner.de to get yourself a quad-core 8Gb RAM bare-metal Internet-connected server with plenty of hard drive space for 50â a month and do with it everything you like, including setting up that file transfer protocol of your liking so that you can store whatever you want on it, however you want. If you want the de-facto gratis option, just share the box with 50 people - paying 1â each for substantially improved privacy plus some spare generic CPU-cycles is good, no? Versus Dropbox I mean, which I agree with you kind of sucks in a way cheap chinese toys do.
That said, good luck! I know this was chosen posted here to kickstart a debate rather than fish out THE ANSWER - the question was "rhetorical" :)
"GUI Revolutions: From Windows 8 to Flashing Bulbs" - there, fixed it for y'all :)
Because it's cheaper than arguing with idiots.
Change your email address, my verbose friend :)