"Out of the box", I have issues with the radeon driver causing nasty flicker problems or simply giving me a fully black screen--of course a live CD run might use the vesa driver and hibernate might work great. On top of that, "out of the box" my wifi adapter isn't supported and I presume it is a major hurdle for the hibernation issue--and yes, I could probably find supported hardware to make this a non-issue. In any case, my main concern is more than a generic live CD run but a real desktop/laptop run which likely with use a nvidia/fglrx driver and that tends to hose any presumed expectation of stability when it comes to sleep/hibernation. Then again, Intel Integrated Graphics are selling well, so you might be technically right.
Still, I don't personally count on sleep/hibernate on my own system since it's simply not worth the headache of it might/might not working. Personally, I'd rather see more advanced user space checkpointing be developed and used, anyways, since hibernate is a pretty gross hack and user space checkpointing has a lot of versatile uses--like pause/quit/start/resuming long-running tasks--with a lot more granularity and avoids most the headaches with much fewer downsides. And as an added bonus, it makes much more reasonable full system shut downs instead of sleep mode which is a gross waste of power as a general point.
You need hardware support to securely encrypt a hibernation file. Otherwise it is a chicken and egg problem. Where do you get the key to decrypt the hibernation file? It would have to be in the hibernation file.
Precisely, in the first block is the previously encrypted private key and the current hibernation files public key encrypted symmetric key.
Either that or ask the user for the security code on resume. Which is valid but obnoxious.
Which is precisely what you should and actually must do or you're vulnerable to the above mentioned attack. The point is that without a security code, anyone who has access to the hibernation file can scour it for whatever keys were in memory at the time of hibernation and possibly even get stuff from previous hibernations (it all depends on if Windows securely wipes the hibernation file when you ask it to delete/recreate it, which unfortunately I don't know).
But backing up, the swap file is also potentially a vulnerable outlet if Bitlocker, PGP, TrueCrypt or whatever every have parts of the key in unlocked memory or just generally once files are unlocked since trolling the swap file for partially read in files may be enough of an issue (imagine otherwise encrypted patient records being recoverable from the swap file because invariable to update them there's a time when a copy of patient records may be in memory, altered, then swapped out before being commited back to the encrypted filesystem; the only way around that is to either lock all memory for programs that access encrypted files, disable swap, or encrypt swap). All that I mentioned has been a known issue for years and is a main reason why Bitlocker was pushed so heavily. But, then, Bitlocker encourages (requires?) TPM to avoid having to enter a security code on resume/startup precisely to be less obnoxious and relies upon TPM being secure enough to protect the Windows OS startup and hence allows Windows permissions to protect the hibernate file. Clearly, that's a failure.
Which is precisely why (1) the hibernation file should be encrypted by default--symmetrically encrypt with a randomly generated key encrypted with a system public key--and (2) the swap file(s) should be encrypted by default--symmetrically encrypted with a randomly generated key that need not be stored but in memory.
As for how Linux hibernation working...it generally doesn't..nor does sleep. Oh, I'm sure there are some people who have gotten it working, but the issue of firmware loading on reboot was only recently solved--sort of--and the lack of aggressive analysis of every driver actually reinitializing properly... *sigh* Yet another inconvenience I put up with Linux. But, then again, I don't have to worry about key leaking.
I'd imagine the year of Linux on the Desktop would go a lot faster if Google devoted itself to ChromeDistro instead of ChromeOS. Then again, I think people already have enough issues with what Ubuntu is doing. I guess this would be the perverse opportunity for a BingDistro.
If you steal $1 from my wallet, I'll have $1 less than I would without your interference. If you copy one of my books rather than buy it, I'll have (let's say) $1 less than I would without your interference.
Um..buying your book *is* interference. It's the act of copying of your books rather than buying it that is not interference. That's why, in the above scenario, no amount of copying makes you personally less any money.
Of course, you may not have bought my book in the first place, and I may have dropped that $1 bill by accident. There's probabilities involved, I know, but that's not the point.
Funny, but do you know the point? The point isn't whether you get that $1 for a copy of your book X. It's that society has agreed that money is a motivator for action by authors--Mark Twain is a great example of that--to write more works and hence authors who write book X and can profit from it--or at least pay off the loan sharks--will be motivated to write book Y and then book Z and the act of copying without payment, while it benefits society directly, has the side effect of longer term halting the production of book Y or book Z because a person who believes their work is worthless may, no matter how much they like writing, practically look elsewhere to feed their kids^W^W^Wpay off their loan shark.
Of course, once you get to that point, you then have to acknowledge that the only way to encourage an author to write book Y or book Z if book X is widely successful is to end the copyright on book X *within an author's lifetime*. In fact, IIRC, a study a few years back says that the optimal copyright term is 14 years. Now, I imagine there's some real world fuzziness to that number because there's such a wide range of medium and their rate of propagation is varied, but the general point stands if anything that copyright is so out of focus to its intent that there's a pretty strong moral argument to ignore it entirely or at least to effectively treat everything 14 years old as not copyrighted.
Well, considering that both Democrats and Republicans are so right leaning, right leaning in the US is so anti-government, and how the US is so money hungry, you'd think all the above would try to avoid being President of the US and work towards being CEO of some random public company where they'd make ten times the money readily... Put another way, perhaps POTUS is a dead-end for the elite.
The problem is that GPUs and high speed graphics libraries are an edge case, just like Google's use of map / reduce. That isn't to say they're not very advantageous in their own field. The point though is that 99% of code isn't GPU or map / reduce and there's been literally decades for functional programming to be made provably the superior option in more than a lot of edge cases.
Further, compiler and CPU theory over the last 3 decades have focused on making all code run faster, not simply C code. It is merely that C code which its highly interdependent structure has seen the most obvious gains. Meanwhile, as you say, functional compilers are a generation ahead because their inherent structure already allows for much better optimization. Yet by the same token, plenty of programs are still not written in a functional style precisely because they do not form into that inherent structure and trying to morph them into such a format is likely to be very suboptimal at best.
And, btw, the reason I'm not holding my breathe for a purely functional language based OS is precisely because Symbolic Lisp machines were such a failure. Do note that RMS was a rather huge supporter of Lisp and it's a significant reason why GNU supports Guile--admittedly much more Scheme-like than Lisp-like--yet pursued a base system of Unix and C. Of course, I believe RMS's original vision was more of a core C/Unix system and most of user space in Guile or another functional language, but then that large didn't materialize because neither scripting languages--a form I think very appealing to most Free supporters--nor even a byte code language lends itself well to the sort of optimal user experience one would desire. Then again, Android is doing quite well, but that's more or less a consequence of the smartphone/low energy platform being a fluid one and trying to avoid any future CPU migration issues--ie, they simply made a virtual architecture and so it has very little to do with language format/structure.
I think my final analysis would be that programmers aren't reasonably capable of giving the system the sort of isolation hints to a compiler be it in a functional, procedural, or whatever language--except that perhaps a genius level programmer may every once in a while manage it for isolated case. If they were, again, 99% of programs and 99% of code would already be functional because of its inherent superiority in compiler-driven optimizations. Instead, 1% of code that would otherwise use 99.9% of CPU time uses closer to 1% of CPU time.:) So the big bottleneck then is the rest of the code that doesn't fall so easily into a pattern and that's why optimizations on non-functional code is so critical. And precisely because humans are unable to reasonable see the pattern of isolations in millions of lines of code, a compiler driven approach that can sieve through the code is the key. And because compilers can't work miracles alone, languages that curtail some of the mutability of C have been born in countless languages while still retaining a lot of the strengths of C to try to give the best of both worlds.
So, I think RMS had it partly right and your statements about further functional incorporation are right at one level. But Perl6, Scala, Clojure, and Haskell are no languages to write a kernel in--not that it may not be technically possible but in that it's rather orthogonal to what a kernel is about, especially when it comes to having a rather clear bounded understanding of execution time, memory usage, etc. Functional programming definitely has its place and there's certainly a lot of places that functional-like structures can be incorporated into a lot of languages to handle readily parallizable edge cases. But none of that handles a lot of the unrealized readily parallizable common cases which few humans are readily able to comprehend. That is, after all, the whole reason resource scheduling in kernels is still a very heavy area of research with still a lot of questions on even static models let alone the sort of real world ones.
Look, I know that on Slashdot it's hip to bash Republicans at every turn, but this is so wrong it's not even funny.
Well, as much as it's hip to bash Democrats, Libertarians, Christians, and a few other large groups in the US...
There are plenty of valid criticisms of the Republican party, and they're certainly not clean on this issue. But to say that they're worse than Democrats on copyright just sounds like uninformed Republican bashing.
Um..Orrin Hatch? Beyond that, Democrats as a platform don't support any ideas of minimal government that would inherently be in conflict with copyright, copyright extensions, etc except as studies have shown the current state is disadvantageous for society. Besides that, I think you hit the root of the point except reworded that "[they're] all in the pocket of Big [Industry] in places like [State] that lean heavilly [Party]". In short, each party is given money from local industries and the party that win is the flavor of the area. I don't think that the actually voted in flavor necessarily radically changes the issues when it's the industries helping to write the laws...
The problem as I see it, though, is precisely the mythic "90+% of code" which is presumed to be related to variable transformation. Yet, if that were the case, functional programs along with functional compilers would already be producing programs substantially faster on vectorizing CPUs. Of course, I know the above isn't that simple and it helps little that poor programmers who can functional languages may well code so badly to miss out on most the compiler benefits. Yet trying to structure everything to fit the theoretical mode of functional languages quickly hits real-world design issues which is precisely who object oriented and procedural languages are still quite common, even if functional languages when well coded for routinely were substantially faster. The end problem after all is compilers and CPUs trying their best to see work done as fast as possible no matter how poorly code is or even must be written vs the potential expectations.
Or, put another way, if there is any solid truth that seems to be pervasive it is that over time an ever growing use of CPU cycles are used to do the same amount of work as of decades past and it is very unclear exactly what steps could reasonably be taken to really eliminate this dilemma in any sensible fashion. Certainly, I'm not holding my breathe for a [near] purely functional language based OS.:) So, instead, I think we're left to further designs of compilers to tackle that mythical 10-% of code which, I think, may well account for much closer to 99% of code on many systems.:/
Interesting point, I see. So it is the compiler that isolates state not the programmer and the hope is that the compiler sees a path for parallelizing via. implicit isolation?
More a combination of both, really. Programmers already do it all the time in object oriented programming though encapsulation and method-based access. Add to that language-based opaque referencing being the norm and compilers already have a lot of information on the pretty explicit isolation. Like I was trying to say, functional languages just lend themselves better to the obvious cases of isolation given the nested structure of functions.
I gotta tell you I don't see that working for anything but a trivial program in practice.
And I'd say, that's the big weakness in functional languages as well. You can try very hard and try to wrap everything you do in a functional way yet in the end you're fundamentally trying to restructure your own thought processes under some mostly vain hope the compiler will compile and dish out the right optimizations. Without a lot of extensive refactoring, though, you end up losing out on a lot of actually substantial benefits because it's often unclear exactly where the bottlenecks are or simply how much could be gained though extensive and pervasive small scope parallelizing throughout all of the code. This is, after all, the primary basis for superscalar architectures and their clear superior processing power over simple pipelined architectures.
Synchronizing state like J2EE / J3EE does is hard. It just strikes me as a lot easier to bite the bullet. But the.NET compiler is an excellent compiler.
Well, the simple fact is that compiler writing is hard. I mean, it's trivial enough to write a compiler to take simple code and output a very direct translation. But the second you deal with every last possible technical valid variation under the scope of a language standard that doesn't really entirely jive with the expectation of programmers and couple that with all the potential bugs introduced while adding parallelism... This is no doubt the reason why the ia64 was such a colossal failure.
So I'd tend to agree with biting the bullet if for no other reason that we've yet to reach the state of the art in compiler design to actually make the ia64 or similar architectures shine--and it's not like we haven't had GCC to be the sort of living-laboratory for every compiler writieri n the world to gain the fame to actually successfully architect such a thing (and for all us simpler programmers to benefit from the genius level voodoo and potentially extrapolate it onto other projects) so it rather hints that such a design may be impractial.
Still, since functional languages merely shift the road blocks instead of really removing them...and push towards having genius level voodoo programmers in every application for optimizing at that level...I'd still rather MS Research and others actually further their compiler designs.:)
Mainstream language have mutable state all over the code. Functional programming's big change on state issues is to careful isolate state.
Isolating state isn't per se the issue. Most mainstream languages isolate state as part of their automatic garbage collection. Yet, they still offer a high level of mutability. No, what functional programming's offer more fundamentally is closures, as you note. That translates into a much clearer tree-based observation of state. Ie, what functional programming languages offer is not per se protection from mutable state but a clear outline on exactly how one would go about writing a parallelizing compiler.
Meanwhile, non-functional languages lack the structure that make such changes as apparent. Isolated state does very little for a compiler writer who can't easily comprehend the structure of the program. Of course, the same is actual true in functional programs as well: the compiler will shine in parallelizing and optimizing the lower-level functional parts yet not inherently understand or parallelize the overall groupings of functions. To that end, a more generic optimizing and parallelizing compiler is needed that can break down entire programs. And that's precisely what MS Research did by being able to effectively tree structure everything.
Put another way, a parallelizing functional compiler only works as well as the programmer who structures the program to isolate state in a fashion that allows for the compiler to recognize that isolated state in the right level of nesting. But a truly parallelizing compiler can observe the actual level of isolated state and work on that and not just hope the programmer did a good job.
Yeah, that'll teach them to do exactly what pirates have been insisting major publishers should do! How dare they give us the option to pay what we want!? They must be punished!!
Actually, no, they're not being punished; they're just not being rewarded. In fact, I rather like the idea suggested precisely because it shows a lot of "would-be pirates" actually would and do have money and would spend it to get games. The fact that THQ won't see a dime of it is THQ's own damn fault for the DRM. I mean, as a Linux user, the DRM really makes it near a full stop to even consider it; without the DRM, I'd probably plop down the money and be content enough even if none of it worked under wine. But, to have to go out of my way and defeat something that even further is trying to stop me from playing? Yea, no thanks.
They are all Clean, Especially in the US and Western European countries. Even China is building new clean coal plants.
Not unless all the old coal plants are going offline/converting.
In the US, All coal plants have scrubbers, all new plants used fluidized bed boilers [energy.gov], and many are starting on CO2 sequestration. In most cases, they are as clean as gas plants, and some are ahead of gas plants on sequestration projects.
Unfortunately, even with scrubbers, coal plants are responsible for ~33% of mercury pollution in the US. The good news is fluidizied bed boilers seem to do a good job of reducing mercury pollution (from ~10% to ~0.1% of standard coal plants). The bad news is that a lot of coal plants are unlikely to suddenly shut down or convert (if possible) to fluidized bed boilers unless forced to which even optimistically would involve years of debate and probably a 10+ year conversion window. As for CO2 sequestration...how's that working out again? Btw, comparing to gas plants is rather a moot point from a CO2 perspective since the overall point of comparison is total CO2 output, not simply doing a bit better than another energy source.
You can continue to demonize clean coal [energy.gov] all you want. It makes you trendy. But it doesn't make you right. Just makes you look uninformed.
Well, please enlighten us again how turning solid carbon happily buried in the ground and turning it into a gas bodes for any attempt to sequester the stuff reliably and economically? The best idea I've ever heard of involves simply burying an equivalent mass of carbon from plants or some other carbon-heavy life form. All ideas to liquify or solidify CO2 in some other fashion--be they through pressure or whatever--and pushing it back into the ground seem fool-hearty as best and a disaster waiting to happen at worst.
Oh, and as snarky as the above comment is, I'm quite serious on the point on wanting to be informed. My understanding of the physics of the situation would seem to indicate that any method to get CO2 into a stable-enough form would involve a chemical reaction to make it solid/liquid at high pressure and about room temperature; and I've yet to hear of an economic way to go about doing that--presuming the whole burying plants/algae/whatever is not actually economical. Even then, I don't see coal plants adoption that unless forced to, just like the scrubbers, and let me reiterate the whole 10+ year timeline, at best. Of course, given just how pro-business Congress is in general and how, well, stupid Republicans are on the whole CO2/global warming thing is...I can only imagine they'll never act if they have the option.
Yesterday you received a Policy Brief or [sic] copyright law that was published without adequate review within the RSC and failed to meet that standard.
Yesterday you received a Policy Brief of copyright law that was published without adequate scrubbing of any truth or fact the RSC sets as a standard for supporting, so I'm disavowing the brief after the fact.
Copyright reform would have far-reaching impacts, so it is incredibly important that it be approached with all facts and viewpoints in hand.
Copyright reform could severely cut into campaign contributions--contributions that amount to little more than kick backs from rent seekers over the economically unsound practices that the Policy Brief spells out--, so it's incredibly important that we allow the copyright industry to present "facts" and present their "viewpoints" to counter anything that the brief lays out. I mean, sure, we don't do the same thing when it comes to climate research or currently illegal drug studies. But, we really don't want to fiddle around with the status quo and upset our power base. I mean, did you really thing think we were any less in bed with Hollywood than the Democrats? We'll gladly take their money; we just wish they were less gay or liberal or whatever.
Where does it end, though? You speak of "the internet in [its] raw form", yet the internet only portrays a very small part of reality itself. As repellent and sordid and shocking those images of "horse riding" were, there is much, much worse things in reality. And to protect "children", all the other mediums (newspapers, radio, TV) consistently self-censor that content. Hell, whenever any other medium even begins to really show the "raw form" of reality, there's calls to ban the works or to cry out how it's all being done for ratings and shock--look no further than rap music.
Yet in doing this, I think most people speak against these things not for "children" but for themselves. It's better to hear a few chilling numbers of people being killed than to see their bloody corpses. It's easier to ban a few foul worded rap songs than to hear the horrors of the ghetto. Do you see a pattern? Censorship or even self-censorship are the things that help turn a blind eye to the problems that we, the people, either cause or refuse to help fix. For instead of figuring out more about "horse riding" and seeing if (a) it's healthy over all and the shame/disdain should be removed or (b) it's unhealthy and the people involved should be helped, you want to just turn your eyes away.
For the children, indeed.
PS - And yes, there are indeed shock sites for the sake of shock and assholes who seek merely to offend. But I think it a disservice to your children to merely try to block this truth than to try to educate them. It's a much harder thing to teach a child how to discern good from evil, bad from merely a preference, and where the line should be that one should help out another or merely mind one's own business. It's certainly not so clear as to use a static piece of software to do the job or to pretend that any other person or parent is in a position to really indirectly teach your child what you yourself should be instilling in them. Yea, that does invariably translate into tons of awkward moments where you have to give satisfying answers to exactly what "horse riding" is and why such content exists. But, then, a large part of that awkwardness stems from probably not having a good answer for oneself. And it's through one's children that one vicariously gets to relive childhood and hopefully do a better job at removing that awkwardness for the next generation.
In other news, Google releases android 4.2 with a new camera, a new keyboard, and smoother rendering. They aren't porting any of these features back to 2.3 or 4.0. Is this what it's come to?
Out of curiosity, is there anything legally preventing someone from backporting those new android 4.2 features to 2.3 or 4.0? Is there a reason why people would prefer sticking with Android 2.3 or 4.0 instead of performing the 4.2 upgrade--and before you suggest something along the lines of their carrier preventing an upgrade, I'd note that they're just as likely to prevent receiving backports--?
Linux has incorporated btrfs into the 3.x kernel and isn't porting it back to the 2.4 kernel. Is this what it's come to? Etc. etc. etc.
So, Direct X is comparable to a kernel level module--ie, a driver? Yet with Windows 7 and 8's driver compatibility, Direct X for Windows 8 cannot be used with Windows 7? Or is Direct X comparable to a system level library? How many system-level libraries/programs in Linux don't work on 2.4 and 3.x kernels? Well, what about it being a user-level...no, there's supposed to be great backwards compatibility there too.
Yes, this is Slashdot, but the MS bashing was played out sometime around 2006. If you're going to pick on them, at least pick something legitimate and don't whine about them not backporting features ad-infinitum.
It's hardly "ad-infinitum" to note that MS has a long track record of releasing a new version of Windows with a slight improvement in some programs or libraries that are in themselves desirable, possibly only minimally and only to some people, but inherently break future backwards compatibility for programs that target those new features and hence produce the impetus for people to upgrade in the long term. After all, the argument isn't being made that Direct X 11.1a should target Windows 98 or Windows 2000. The statement of note is precisely what about the new features of Direct X 11.1a that have reason to be targeted at Windows 8 and hence would reasonably justify not making a more broad/generic release that would work on Windows 7 or even Windows Vista.
Of course, maybe it's precisely that the developers of Direct X are so keen to use the latest features of the latest libraries that MS makes and hence inherently creates the current scenario. But, you know, that's just rather bad. Why? Because the latest features of the latest libraries are almost certainly going to be buggier than tried and true, older libraries based upon older features. In either case, it's rather unclear on precisely why Direct X 11.1a should be a Windows 8 exclusive. Certainly, some generic remark that backporting doesn't always happen is just hand waving that misses the specific points that could be raised.
Yeah. Windows 8 is great. It's so much better at protecting users from malware. It's even 85% effective against trojans. It's just tons better than Linux security wise.
Now that that's out of the way, am I really at all guaranteed that (a) I won't be infected with malware with Windows 8 or at least (b) that if there is malware installed on the system some how, all the files that compose it will be clearly marked, grouped together, and easily deleted from the system? Because as a Windows user, I really don't care how insecure Linux or Mac OS X might be. What I do care about is dealing with the malware threat(s) that actually exist that effect me. And everything you've stated about beefed security has, AFAIK, not stood up to the test of time. At best, they've mitigated the risks and still resulted in tons of malware infections that may some day effect me.
Windows has Windows Resource Protection [wikipedia.org] (WRP). Unlike Linux/Unix, even if you run as an administrator (equivalent to root) you *do not* have permission to change operating system files. Only the TrustedInstaller account can change those files.
Sounds like TrustedInstaller then is more analogous to root, then. No, really, it sounds like Windows has some SELinux role features. Admittedly, Windows had it first but just like with SELinux it didn't obtain any sort of regular adoption because it introduces an extra level of complexity that makes it harder for the average user to manage their own system. And attempts to try to automate around that issue end up invariably just being another place that becomes an attack vector.
Furthermore, the files are designated system integrity level raising another barrier. Even if a malicious process succeeds in fooling a user into elevating to high integrity level with administrator privileges, it cannot change those files. WRP also performs integrity checks upon system start. If any files have been tampered with they are restored from an encrypted cache before they are accessed. Is guaranteed security? no - but it pretty good protection and it is unlike anything you'll find in Linux/Unix where root access == pwned.
All of the above would be important if, oh, malicious processes need to be root to auto run or otherwise do 99% of the stuff they want to do. No, the only major thing the above does is make it harder to write a root kit. But malware doesn't have to be a root kit to be a major annoyance to remove.
Windows has Kernel Patch Protection [wikipedia.org] (KPP). KPP encrypts and checksums certain OS tables of the running operating system to prevent tampering by rogue processes which somehow have gained kernel access (e.g. through a vulnerable driver). A rogue kernel process will attempt to patch itself in so that it may intercept disk accesses, network access etc. If KPP determines tampering it will halt the system. Is guaranteed security? no - but it is unlike anything you'll find in Linux/Unix.
Right because in Linux land, 99% of drivers are open source and included with the kernel. That is to say, there can be static analysis of the code to much more readily guarantee against kernel tampering. Beyond that, yes, the more noticeable examples of closed drivers (gfx card and wifi) are a real problem, but something like KPP is at best a hack to the problem. For the rest, trying to prevent local system escalation is generally more important anyways to prevent that vector of attack. But as I noted, it only tends to matter with root kits.
Windows has a kernel mode signing policy [microsoft.com] which requires all software (drivers and more) which are to be loaded in kernel space to be digitally signed. If they are not signed they cannot be loaded. If a driver has been tampered with, the signature will be invalid and the kernel will refuse to load it. Ubuntu and Fedora now does have some signing protection, but they are incomplete in comparison, e.g. they only protect executable modules, not configuration files.
Funny thing about digitally signed code. Even if it were a guarantee that you know where the code came from, it doesn't mean it's secure either by design or just general developer failings--look no further than Sony or the countless examples of security vulnerabilities in gfx card drivers. In fact, there was a nice little article about AMD drivers--digitally signed, mind you--disabling ASLR because it was incompatible with it. Since then, the AMD drivers have been updated and certainly ASLR was no panacea anyways. The point still stands that with all the testing that MS does before signing drivers, they let such a gaping hole right on through. And I state this not because I don't think MS seriously tries. It's just that KPP and unit testing are the sort of static test
Yikes, what a mess. The "guts" are fine - it seems exactly like Windows 7. But the interface is going to go down as a "teachable moment" at colleges, I think. It is quite literally two completely separate GUIs crudely duct-taped together. It's a lot like running a virtualized instance of another OS on a separate screen. The one side is mostly unaware of what the other side is doing. They even have two totally separate "control panels" now.
You've basically just described Linux. I mean, good luck trying to harmonize the appearance or behavior of programs in Linux. KDE4/KDE3/GTK3/GTK2/etc and trying to make them all use the same theme, color scheme, fonts, font rendering, etc... And of course there's all the odd-ball applications (Chrome comes to mind) that want to look different to get noticed. Of course, that's the excuse that every app and UI goes with and the reason that nearly every new release has to look different just to convince you to upgrade even if it's just to make the buttons rounder or shiner or whatever.
Oh, and just for laughs, yes, Apple is just as guilty of this. I just don't really give a fuck about Apple.
This is a stupid non-story. The reason Microsoft has ads (besides a desire to make money) is that these features are delivering content that costs money.
Um..and? You make it sound like MS puts ads on, oh, WMP to cover the h264 licensing fees. No, wait, you end up paying MS a set fee--the cost of the OS--and they figure out how to pay whatever licensing fees or whatever out of that. The same for hosting and maintaining microsoft.com.
Microsoft is providing a premium service through the ad supported apps.
Wow, such a premium service to wrap a web page *with ads* in an app. You know, to me, that sounds like the exact opposite of a premium service.
And these are also applications which aren't a part of the core OS experience. If you don't want them... uninstall and pick another app without ads.
Well at least you can remove them. Good thing they didn't make it the "ad delivery engine" and tie IE into using it as a core service. Or just generally, they could have made the "ad delivery engine" to allow for ad-supported apps for an app store...which would be a great thing to hack to block the ads and effectively get a lot of free apps. I guess that sort of begs the question, what sort of legal situation are you in if you do block the ads?
Say the Surface's memory is evenly divided into 16 GB for the operating system and included applications and 16 GB for third-party applications, with all music and movies on a microSD card. What kind of application collection takes up 16 GB, other than a bunch of hardcore games?
Apparently "the operating system and included applications". Really, though, that statement basically begs the question of "is Windows RT really that bloated?" or "didn't you just answer your own question?". And that doesn't even get into the point of people wanting to, oh, dual boot Linux on the thing... This is/., after all.:)
I thought hardcore games weren't ported to Windows RT, and most apps and casual games were far smaller than that.
Well, if MS Office and whatever else is in the MS offering is allowed to be bloated like that, surely the OSS equivalents which will be side installed--can you remove those "included applications"?--by the die hard OSS people--go figure why they'd buy an MS Surface Tablet...--are allowed to take up gobs of space too. Seriously, though, this is one reason I'm still not sold on tablets in general--beyond all the ways they're generally inferior to a laptop for lacking a keyboard; the storage capacity isn't reasonably there for one's music/movie collection. But, then, I'm the sort of person who wants to buy a NewsRadio collection, rip it to disk, and then be able to play it anywhere on my shiny new tablet without (a) reencoding it down just for the tablet or (b) considering buying a separate SD card just for it (or it and one other thing). HDs are still king for storage and just not a good idea for tablets. So, I think the world is reasonably at an impasse for at least a few years until internal storage capacity doubles a few more times. Ie, the year of the tablet may actually be at hand and not just a fun fad.:/
As such, being hacked doesn't immediately mean a financial or business impact. Hackers stole 100,000 encrypted database tables, well so what? Do you disclose worst case scenario if they attackers can decrypt them or do you just assume they won't be able to break the encryption. My bet would be companies would go the later route.
Given your statement aobout companies being rat bastards, why would you believe they even *have* encrypted database tables? And if they do, what are the odds the key is stored on the same machine--ie, they only encrypted the table due to some contract specifying it but the contract failed to exclude the obvious "and the key can't be on the same machine"? But, yea, most companies are likely to try to downplay the risk.
Also translating lost data into dollars usually looks really bad.
That's a good thing if it's for the tax man--you can report an operating loss. And it's a bad thing to tell shareholders--who want the paper value of the company to go up. Never the less, if the company has an dollar loss as a result of a hack, why wouldn't they tell it? As for the hypothetical lost value from lost data? You report to shareholders the lost data and the potential lost value, both best case and worst case and an argument on how you think things will play out and why. Ie, you simply try your best to inform them because...tada..they're the owner(s) and deserve no less.
For example.
When prosecuting the case and determining damages, they will include the cost of reporting to each individual effected, labor, envelopes, stamps, etc. At a 2-3$ per person this adds up quick.
Um..is the discussion really about mailing an envelope to everyone potentially effected every time? Or is it to (a) include a report in the quarterly stockholder information you're already handing out and (b) handing a report to the SEC (and maybe the media, if appropriate) to allow them to disseminate the information to the broader community?
That doesn't cover loss of revenue, business deals and who knows what. So on one hand you want to stick it to the people who attacked you but not spook your investors. Tricky situation, most companies instead just sweep it under the rug.
And the question then becomes, and at what point is this not just fraud? If a company finds out the food they shipped out may be contaminated, they may *want* to sweep it under the rug, but to do so is most often simply illegal under various regulations. But without even the regulations, for a company to continually and knowingly to misrepresent itself just to not "spook your investors"? That's not how the world works. The only thing you can do is to try to spin the facts as best you can to adequately prepare those investors so they aren't overly spooked. But if there's a data breach and there's reason to be spooked, no amount of spin will or should help you.
In the end, as you say, it comes down to what "they should [do] but they won't". The real question is what, if anything, should be done on the societal, investor, and/or governmental end. The point that another poster raised, that most people shouldn't be investing in the stock market is quite cogent to this point. Society as a whole won't punish bad companies, generally. Government is too often too slow to act to have much effect--unless it's a long-term pattern of abuse. The only real recourse then is enough investor involvement, not simply to make a buck but to be involved enough to replace managers and CEOs who are so inclined to "sweep it under the rug". This also means working more towards making sure future data breaches are less likely to happen. But, even under such a scheme it's far from perfect, as enough big time speculators can game, manipulate, etc the stock market--and there's a long history of it in the past--which makes the idea of an investor driven stock market perhaps more of a pipe dream than a reality, anyways.
Considering how much Republicans (and I imagine most rich Democrats) hate the Estate Tax...
Seriously, though, the humor to me of it all is how the argument for why Estate taxes are so evil--that they take away a life time of effort and simply hand it over to a government that didn't earn it like the person did. Well, people, you can't take your money to your grave. That gold ring on you finger won't look too pretty on your rotting body or eventually your brittle skeleton. When you're dead, you're dead.
Besides, the idea of being able to hand out big chunks of estate to people of your choosing really goes against the whole idea of equal opportunity when those gifts are given to children, grandchildren, etc. Meanwhile, one can give tax exempt gifts of scholarship, medical payments, *cough* political organizations, and tax deductible gifts--which go against the idea of equal opportunity but at least don't seem focused on simply allowing for self-supporting dynasties.
Really, I think it all comes down to the fact that I've never heard of a solid explanation on how property can come into ownership into the first place--simply saying "me first" is an absurd justification given just minimally that there's no way to really know if you're first. Nor is there a solid explanation on how property can be properly abandoned--be it through natural death or murder--not unlike the issue of whether a copyrighted work can sensically be put into the public domain. In the end, it's all a level of arbitrary government sanctioned rules. And once you're at that point, then the Estate Tax or a Gift Tax make as much sense as anything else.
If the CCTV cameras do in fact prevent crime (and BTW are therefore not just security theatre) what's wrong with that?
Security theatre works some times because some criminals are (a) stupid enough to believe it's real and/or (b) stupid enough to be caught by the very bad security actors. As for what's wrong with it, how about that it treats 100% of the populace as very potential criminals and is generally creepy?
Other than infringing on some imaginary right to commit crimes with assured privacy in public spaces, what is the problem exactly?
Oh, I don't know... Perhaps it has something to do with CCTVs are like locks, they help keep honest people honest (ie, they work to keep the already low crime rate marginally lower); meanwhile, constantly tracking overwhelming honest people in public spaces is very dickish. So, hey, it might well be perfectly legal to do. That doesn't mean I really want to do business with dicks.
But, blah blah blah, Nineteen Eighty Four was a warning not a blueprint, blah blah blah.
No, that's the wrong book. You want something closer to It Can't Happen Here. Of course, the truth is the whole government involvement isn't needed when enough companies go along with it and enough people are complicit in letting it happen. The funniest part is that "for the children" is almost certainly the excuse. "For the children" is how smutty or even semi-smutty magazines were banned from the shelves--yet still available behind the counter. Meanwhile, "for the children" is used to justify CCTV to catch potential creepy perps running off with their kids--a very uncommon thing--and meanwhile it ignores that CCTV can be constantly used by creepy perps to stare at their kids--made even creepier with the whole TSA body scanners.
In short, it really comes down to priorities and who people place their faith in. What Creepy Cameraman really proves is that no matter what, there's a person behind the camera and they could be just as creepy as he is. So, it's hard for me to place a lot of faith in CCTVs as a general point.:/
Actually I think it's more like trying to get them to steal from the guy down the street rather than you.
I don't really disagree, but then that's paramount to promoting theft--and something I don't think most companies would openly admit to.:) And the UK, of course, takes it to the extreme and tries to make it "steal from the [country] down the [channel] rather than [us]", which is obviously absurd. But, then, that's why I call it all security theater. But, then, in the UK, I guess that'd be security theatre...
Slashdot Mirror
"Out of the box", I have issues with the radeon driver causing nasty flicker problems or simply giving me a fully black screen--of course a live CD run might use the vesa driver and hibernate might work great. On top of that, "out of the box" my wifi adapter isn't supported and I presume it is a major hurdle for the hibernation issue--and yes, I could probably find supported hardware to make this a non-issue. In any case, my main concern is more than a generic live CD run but a real desktop/laptop run which likely with use a nvidia/fglrx driver and that tends to hose any presumed expectation of stability when it comes to sleep/hibernation. Then again, Intel Integrated Graphics are selling well, so you might be technically right.
Still, I don't personally count on sleep/hibernate on my own system since it's simply not worth the headache of it might/might not working. Personally, I'd rather see more advanced user space checkpointing be developed and used, anyways, since hibernate is a pretty gross hack and user space checkpointing has a lot of versatile uses--like pause/quit/start/resuming long-running tasks--with a lot more granularity and avoids most the headaches with much fewer downsides. And as an added bonus, it makes much more reasonable full system shut downs instead of sleep mode which is a gross waste of power as a general point.
Precisely, in the first block is the previously encrypted private key and the current hibernation files public key encrypted symmetric key.
Which is precisely what you should and actually must do or you're vulnerable to the above mentioned attack. The point is that without a security code, anyone who has access to the hibernation file can scour it for whatever keys were in memory at the time of hibernation and possibly even get stuff from previous hibernations (it all depends on if Windows securely wipes the hibernation file when you ask it to delete/recreate it, which unfortunately I don't know).
But backing up, the swap file is also potentially a vulnerable outlet if Bitlocker, PGP, TrueCrypt or whatever every have parts of the key in unlocked memory or just generally once files are unlocked since trolling the swap file for partially read in files may be enough of an issue (imagine otherwise encrypted patient records being recoverable from the swap file because invariable to update them there's a time when a copy of patient records may be in memory, altered, then swapped out before being commited back to the encrypted filesystem; the only way around that is to either lock all memory for programs that access encrypted files, disable swap, or encrypt swap). All that I mentioned has been a known issue for years and is a main reason why Bitlocker was pushed so heavily. But, then, Bitlocker encourages (requires?) TPM to avoid having to enter a security code on resume/startup precisely to be less obnoxious and relies upon TPM being secure enough to protect the Windows OS startup and hence allows Windows permissions to protect the hibernate file. Clearly, that's a failure.
Which is precisely why (1) the hibernation file should be encrypted by default--symmetrically encrypt with a randomly generated key encrypted with a system public key--and (2) the swap file(s) should be encrypted by default--symmetrically encrypted with a randomly generated key that need not be stored but in memory.
As for how Linux hibernation working...it generally doesn't..nor does sleep. Oh, I'm sure there are some people who have gotten it working, but the issue of firmware loading on reboot was only recently solved--sort of--and the lack of aggressive analysis of every driver actually reinitializing properly... *sigh* Yet another inconvenience I put up with Linux. But, then again, I don't have to worry about key leaking.
I'd imagine the year of Linux on the Desktop would go a lot faster if Google devoted itself to ChromeDistro instead of ChromeOS. Then again, I think people already have enough issues with what Ubuntu is doing. I guess this would be the perverse opportunity for a BingDistro.
Um..buying your book *is* interference. It's the act of copying of your books rather than buying it that is not interference. That's why, in the above scenario, no amount of copying makes you personally less any money.
Funny, but do you know the point? The point isn't whether you get that $1 for a copy of your book X. It's that society has agreed that money is a motivator for action by authors--Mark Twain is a great example of that--to write more works and hence authors who write book X and can profit from it--or at least pay off the loan sharks--will be motivated to write book Y and then book Z and the act of copying without payment, while it benefits society directly, has the side effect of longer term halting the production of book Y or book Z because a person who believes their work is worthless may, no matter how much they like writing, practically look elsewhere to feed their kids^W^W^Wpay off their loan shark.
Of course, once you get to that point, you then have to acknowledge that the only way to encourage an author to write book Y or book Z if book X is widely successful is to end the copyright on book X *within an author's lifetime*. In fact, IIRC, a study a few years back says that the optimal copyright term is 14 years. Now, I imagine there's some real world fuzziness to that number because there's such a wide range of medium and their rate of propagation is varied, but the general point stands if anything that copyright is so out of focus to its intent that there's a pretty strong moral argument to ignore it entirely or at least to effectively treat everything 14 years old as not copyrighted.
But, then, that's just me.
Well, considering that both Democrats and Republicans are so right leaning, right leaning in the US is so anti-government, and how the US is so money hungry, you'd think all the above would try to avoid being President of the US and work towards being CEO of some random public company where they'd make ten times the money readily... Put another way, perhaps POTUS is a dead-end for the elite.
The problem is that GPUs and high speed graphics libraries are an edge case, just like Google's use of map / reduce. That isn't to say they're not very advantageous in their own field. The point though is that 99% of code isn't GPU or map / reduce and there's been literally decades for functional programming to be made provably the superior option in more than a lot of edge cases.
Further, compiler and CPU theory over the last 3 decades have focused on making all code run faster, not simply C code. It is merely that C code which its highly interdependent structure has seen the most obvious gains. Meanwhile, as you say, functional compilers are a generation ahead because their inherent structure already allows for much better optimization. Yet by the same token, plenty of programs are still not written in a functional style precisely because they do not form into that inherent structure and trying to morph them into such a format is likely to be very suboptimal at best.
And, btw, the reason I'm not holding my breathe for a purely functional language based OS is precisely because Symbolic Lisp machines were such a failure. Do note that RMS was a rather huge supporter of Lisp and it's a significant reason why GNU supports Guile--admittedly much more Scheme-like than Lisp-like--yet pursued a base system of Unix and C. Of course, I believe RMS's original vision was more of a core C/Unix system and most of user space in Guile or another functional language, but then that large didn't materialize because neither scripting languages--a form I think very appealing to most Free supporters--nor even a byte code language lends itself well to the sort of optimal user experience one would desire. Then again, Android is doing quite well, but that's more or less a consequence of the smartphone/low energy platform being a fluid one and trying to avoid any future CPU migration issues--ie, they simply made a virtual architecture and so it has very little to do with language format/structure.
I think my final analysis would be that programmers aren't reasonably capable of giving the system the sort of isolation hints to a compiler be it in a functional, procedural, or whatever language--except that perhaps a genius level programmer may every once in a while manage it for isolated case. If they were, again, 99% of programs and 99% of code would already be functional because of its inherent superiority in compiler-driven optimizations. Instead, 1% of code that would otherwise use 99.9% of CPU time uses closer to 1% of CPU time. :) So the big bottleneck then is the rest of the code that doesn't fall so easily into a pattern and that's why optimizations on non-functional code is so critical. And precisely because humans are unable to reasonable see the pattern of isolations in millions of lines of code, a compiler driven approach that can sieve through the code is the key. And because compilers can't work miracles alone, languages that curtail some of the mutability of C have been born in countless languages while still retaining a lot of the strengths of C to try to give the best of both worlds.
So, I think RMS had it partly right and your statements about further functional incorporation are right at one level. But Perl6, Scala, Clojure, and Haskell are no languages to write a kernel in--not that it may not be technically possible but in that it's rather orthogonal to what a kernel is about, especially when it comes to having a rather clear bounded understanding of execution time, memory usage, etc. Functional programming definitely has its place and there's certainly a lot of places that functional-like structures can be incorporated into a lot of languages to handle readily parallizable edge cases. But none of that handles a lot of the unrealized readily parallizable common cases which few humans are readily able to comprehend. That is, after all, the whole reason resource scheduling in kernels is still a very heavy area of research with still a lot of questions on even static models let alone the sort of real world ones.
Well, as much as it's hip to bash Democrats, Libertarians, Christians, and a few other large groups in the US...
Um..Orrin Hatch? Beyond that, Democrats as a platform don't support any ideas of minimal government that would inherently be in conflict with copyright, copyright extensions, etc except as studies have shown the current state is disadvantageous for society. Besides that, I think you hit the root of the point except reworded that "[they're] all in the pocket of Big [Industry] in places like [State] that lean heavilly [Party]". In short, each party is given money from local industries and the party that win is the flavor of the area. I don't think that the actually voted in flavor necessarily radically changes the issues when it's the industries helping to write the laws...
The problem as I see it, though, is precisely the mythic "90+% of code" which is presumed to be related to variable transformation. Yet, if that were the case, functional programs along with functional compilers would already be producing programs substantially faster on vectorizing CPUs. Of course, I know the above isn't that simple and it helps little that poor programmers who can functional languages may well code so badly to miss out on most the compiler benefits. Yet trying to structure everything to fit the theoretical mode of functional languages quickly hits real-world design issues which is precisely who object oriented and procedural languages are still quite common, even if functional languages when well coded for routinely were substantially faster. The end problem after all is compilers and CPUs trying their best to see work done as fast as possible no matter how poorly code is or even must be written vs the potential expectations.
Or, put another way, if there is any solid truth that seems to be pervasive it is that over time an ever growing use of CPU cycles are used to do the same amount of work as of decades past and it is very unclear exactly what steps could reasonably be taken to really eliminate this dilemma in any sensible fashion. Certainly, I'm not holding my breathe for a [near] purely functional language based OS. :) So, instead, I think we're left to further designs of compilers to tackle that mythical 10-% of code which, I think, may well account for much closer to 99% of code on many systems. :/
More a combination of both, really. Programmers already do it all the time in object oriented programming though encapsulation and method-based access. Add to that language-based opaque referencing being the norm and compilers already have a lot of information on the pretty explicit isolation. Like I was trying to say, functional languages just lend themselves better to the obvious cases of isolation given the nested structure of functions.
And I'd say, that's the big weakness in functional languages as well. You can try very hard and try to wrap everything you do in a functional way yet in the end you're fundamentally trying to restructure your own thought processes under some mostly vain hope the compiler will compile and dish out the right optimizations. Without a lot of extensive refactoring, though, you end up losing out on a lot of actually substantial benefits because it's often unclear exactly where the bottlenecks are or simply how much could be gained though extensive and pervasive small scope parallelizing throughout all of the code. This is, after all, the primary basis for superscalar architectures and their clear superior processing power over simple pipelined architectures.
Well, the simple fact is that compiler writing is hard. I mean, it's trivial enough to write a compiler to take simple code and output a very direct translation. But the second you deal with every last possible technical valid variation under the scope of a language standard that doesn't really entirely jive with the expectation of programmers and couple that with all the potential bugs introduced while adding parallelism... This is no doubt the reason why the ia64 was such a colossal failure.
So I'd tend to agree with biting the bullet if for no other reason that we've yet to reach the state of the art in compiler design to actually make the ia64 or similar architectures shine--and it's not like we haven't had GCC to be the sort of living-laboratory for every compiler writieri n the world to gain the fame to actually successfully architect such a thing (and for all us simpler programmers to benefit from the genius level voodoo and potentially extrapolate it onto other projects) so it rather hints that such a design may be impractial.
Still, since functional languages merely shift the road blocks instead of really removing them...and push towards having genius level voodoo programmers in every application for optimizing at that level...I'd still rather MS Research and others actually further their compiler designs. :)
Isolating state isn't per se the issue. Most mainstream languages isolate state as part of their automatic garbage collection. Yet, they still offer a high level of mutability. No, what functional programming's offer more fundamentally is closures, as you note. That translates into a much clearer tree-based observation of state. Ie, what functional programming languages offer is not per se protection from mutable state but a clear outline on exactly how one would go about writing a parallelizing compiler.
Meanwhile, non-functional languages lack the structure that make such changes as apparent. Isolated state does very little for a compiler writer who can't easily comprehend the structure of the program. Of course, the same is actual true in functional programs as well: the compiler will shine in parallelizing and optimizing the lower-level functional parts yet not inherently understand or parallelize the overall groupings of functions. To that end, a more generic optimizing and parallelizing compiler is needed that can break down entire programs. And that's precisely what MS Research did by being able to effectively tree structure everything.
Put another way, a parallelizing functional compiler only works as well as the programmer who structures the program to isolate state in a fashion that allows for the compiler to recognize that isolated state in the right level of nesting. But a truly parallelizing compiler can observe the actual level of isolated state and work on that and not just hope the programmer did a good job.
Actually, no, they're not being punished; they're just not being rewarded. In fact, I rather like the idea suggested precisely because it shows a lot of "would-be pirates" actually would and do have money and would spend it to get games. The fact that THQ won't see a dime of it is THQ's own damn fault for the DRM. I mean, as a Linux user, the DRM really makes it near a full stop to even consider it; without the DRM, I'd probably plop down the money and be content enough even if none of it worked under wine. But, to have to go out of my way and defeat something that even further is trying to stop me from playing? Yea, no thanks.
Meanwhile, I'm still waiting for Vessel. :/
Not unless all the old coal plants are going offline/converting.
Unfortunately, even with scrubbers, coal plants are responsible for ~33% of mercury pollution in the US. The good news is fluidizied bed boilers seem to do a good job of reducing mercury pollution (from ~10% to ~0.1% of standard coal plants). The bad news is that a lot of coal plants are unlikely to suddenly shut down or convert (if possible) to fluidized bed boilers unless forced to which even optimistically would involve years of debate and probably a 10+ year conversion window. As for CO2 sequestration...how's that working out again? Btw, comparing to gas plants is rather a moot point from a CO2 perspective since the overall point of comparison is total CO2 output, not simply doing a bit better than another energy source.
Well, please enlighten us again how turning solid carbon happily buried in the ground and turning it into a gas bodes for any attempt to sequester the stuff reliably and economically? The best idea I've ever heard of involves simply burying an equivalent mass of carbon from plants or some other carbon-heavy life form. All ideas to liquify or solidify CO2 in some other fashion--be they through pressure or whatever--and pushing it back into the ground seem fool-hearty as best and a disaster waiting to happen at worst.
Oh, and as snarky as the above comment is, I'm quite serious on the point on wanting to be informed. My understanding of the physics of the situation would seem to indicate that any method to get CO2 into a stable-enough form would involve a chemical reaction to make it solid/liquid at high pressure and about room temperature; and I've yet to hear of an economic way to go about doing that--presuming the whole burying plants/algae/whatever is not actually economical. Even then, I don't see coal plants adoption that unless forced to, just like the scrubbers, and let me reiterate the whole 10+ year timeline, at best. Of course, given just how pro-business Congress is in general and how, well, stupid Republicans are on the whole CO2/global warming thing is...I can only imagine they'll never act if they have the option.
That's obvious. Both. Or do you really think Perl/PHP scripts work because they're computational sound?
Yesterday you received a Policy Brief of copyright law that was published without adequate scrubbing of any truth or fact the RSC sets as a standard for supporting, so I'm disavowing the brief after the fact.
Copyright reform could severely cut into campaign contributions--contributions that amount to little more than kick backs from rent seekers over the economically unsound practices that the Policy Brief spells out--, so it's incredibly important that we allow the copyright industry to present "facts" and present their "viewpoints" to counter anything that the brief lays out. I mean, sure, we don't do the same thing when it comes to climate research or currently illegal drug studies. But, we really don't want to fiddle around with the status quo and upset our power base. I mean, did you really thing think we were any less in bed with Hollywood than the Democrats? We'll gladly take their money; we just wish they were less gay or liberal or whatever.
PS - I think we all saw this coming. :/
Where does it end, though? You speak of "the internet in [its] raw form", yet the internet only portrays a very small part of reality itself. As repellent and sordid and shocking those images of "horse riding" were, there is much, much worse things in reality. And to protect "children", all the other mediums (newspapers, radio, TV) consistently self-censor that content. Hell, whenever any other medium even begins to really show the "raw form" of reality, there's calls to ban the works or to cry out how it's all being done for ratings and shock--look no further than rap music.
Yet in doing this, I think most people speak against these things not for "children" but for themselves. It's better to hear a few chilling numbers of people being killed than to see their bloody corpses. It's easier to ban a few foul worded rap songs than to hear the horrors of the ghetto. Do you see a pattern? Censorship or even self-censorship are the things that help turn a blind eye to the problems that we, the people, either cause or refuse to help fix. For instead of figuring out more about "horse riding" and seeing if (a) it's healthy over all and the shame/disdain should be removed or (b) it's unhealthy and the people involved should be helped, you want to just turn your eyes away.
For the children, indeed.
PS - And yes, there are indeed shock sites for the sake of shock and assholes who seek merely to offend. But I think it a disservice to your children to merely try to block this truth than to try to educate them. It's a much harder thing to teach a child how to discern good from evil, bad from merely a preference, and where the line should be that one should help out another or merely mind one's own business. It's certainly not so clear as to use a static piece of software to do the job or to pretend that any other person or parent is in a position to really indirectly teach your child what you yourself should be instilling in them. Yea, that does invariably translate into tons of awkward moments where you have to give satisfying answers to exactly what "horse riding" is and why such content exists. But, then, a large part of that awkwardness stems from probably not having a good answer for oneself. And it's through one's children that one vicariously gets to relive childhood and hopefully do a better job at removing that awkwardness for the next generation.
Out of curiosity, is there anything legally preventing someone from backporting those new android 4.2 features to 2.3 or 4.0? Is there a reason why people would prefer sticking with Android 2.3 or 4.0 instead of performing the 4.2 upgrade--and before you suggest something along the lines of their carrier preventing an upgrade, I'd note that they're just as likely to prevent receiving backports--?
So, Direct X is comparable to a kernel level module--ie, a driver? Yet with Windows 7 and 8's driver compatibility, Direct X for Windows 8 cannot be used with Windows 7? Or is Direct X comparable to a system level library? How many system-level libraries/programs in Linux don't work on 2.4 and 3.x kernels? Well, what about it being a user-level...no, there's supposed to be great backwards compatibility there too.
It's hardly "ad-infinitum" to note that MS has a long track record of releasing a new version of Windows with a slight improvement in some programs or libraries that are in themselves desirable, possibly only minimally and only to some people, but inherently break future backwards compatibility for programs that target those new features and hence produce the impetus for people to upgrade in the long term. After all, the argument isn't being made that Direct X 11.1a should target Windows 98 or Windows 2000. The statement of note is precisely what about the new features of Direct X 11.1a that have reason to be targeted at Windows 8 and hence would reasonably justify not making a more broad/generic release that would work on Windows 7 or even Windows Vista.
Of course, maybe it's precisely that the developers of Direct X are so keen to use the latest features of the latest libraries that MS makes and hence inherently creates the current scenario. But, you know, that's just rather bad. Why? Because the latest features of the latest libraries are almost certainly going to be buggier than tried and true, older libraries based upon older features. In either case, it's rather unclear on precisely why Direct X 11.1a should be a Windows 8 exclusive. Certainly, some generic remark that backporting doesn't always happen is just hand waving that misses the specific points that could be raised.
Yeah. Windows 8 is great. It's so much better at protecting users from malware. It's even 85% effective against trojans. It's just tons better than Linux security wise.
Now that that's out of the way, am I really at all guaranteed that (a) I won't be infected with malware with Windows 8 or at least (b) that if there is malware installed on the system some how, all the files that compose it will be clearly marked, grouped together, and easily deleted from the system? Because as a Windows user, I really don't care how insecure Linux or Mac OS X might be. What I do care about is dealing with the malware threat(s) that actually exist that effect me. And everything you've stated about beefed security has, AFAIK, not stood up to the test of time. At best, they've mitigated the risks and still resulted in tons of malware infections that may some day effect me.
Sounds like TrustedInstaller then is more analogous to root, then. No, really, it sounds like Windows has some SELinux role features. Admittedly, Windows had it first but just like with SELinux it didn't obtain any sort of regular adoption because it introduces an extra level of complexity that makes it harder for the average user to manage their own system. And attempts to try to automate around that issue end up invariably just being another place that becomes an attack vector.
All of the above would be important if, oh, malicious processes need to be root to auto run or otherwise do 99% of the stuff they want to do. No, the only major thing the above does is make it harder to write a root kit. But malware doesn't have to be a root kit to be a major annoyance to remove.
Right because in Linux land, 99% of drivers are open source and included with the kernel. That is to say, there can be static analysis of the code to much more readily guarantee against kernel tampering. Beyond that, yes, the more noticeable examples of closed drivers (gfx card and wifi) are a real problem, but something like KPP is at best a hack to the problem. For the rest, trying to prevent local system escalation is generally more important anyways to prevent that vector of attack. But as I noted, it only tends to matter with root kits.
Funny thing about digitally signed code. Even if it were a guarantee that you know where the code came from, it doesn't mean it's secure either by design or just general developer failings--look no further than Sony or the countless examples of security vulnerabilities in gfx card drivers. In fact, there was a nice little article about AMD drivers--digitally signed, mind you--disabling ASLR because it was incompatible with it. Since then, the AMD drivers have been updated and certainly ASLR was no panacea anyways. The point still stands that with all the testing that MS does before signing drivers, they let such a gaping hole right on through. And I state this not because I don't think MS seriously tries. It's just that KPP and unit testing are the sort of static test
You've basically just described Linux. I mean, good luck trying to harmonize the appearance or behavior of programs in Linux. KDE4/KDE3/GTK3/GTK2/etc and trying to make them all use the same theme, color scheme, fonts, font rendering, etc... And of course there's all the odd-ball applications (Chrome comes to mind) that want to look different to get noticed. Of course, that's the excuse that every app and UI goes with and the reason that nearly every new release has to look different just to convince you to upgrade even if it's just to make the buttons rounder or shiner or whatever.
Oh, and just for laughs, yes, Apple is just as guilty of this. I just don't really give a fuck about Apple.
Um..and? You make it sound like MS puts ads on, oh, WMP to cover the h264 licensing fees. No, wait, you end up paying MS a set fee--the cost of the OS--and they figure out how to pay whatever licensing fees or whatever out of that. The same for hosting and maintaining microsoft.com.
Wow, such a premium service to wrap a web page *with ads* in an app. You know, to me, that sounds like the exact opposite of a premium service.
Well at least you can remove them. Good thing they didn't make it the "ad delivery engine" and tie IE into using it as a core service. Or just generally, they could have made the "ad delivery engine" to allow for ad-supported apps for an app store...which would be a great thing to hack to block the ads and effectively get a lot of free apps. I guess that sort of begs the question, what sort of legal situation are you in if you do block the ads?
Apparently "the operating system and included applications". Really, though, that statement basically begs the question of "is Windows RT really that bloated?" or "didn't you just answer your own question?". And that doesn't even get into the point of people wanting to, oh, dual boot Linux on the thing... This is /., after all. :)
Well, if MS Office and whatever else is in the MS offering is allowed to be bloated like that, surely the OSS equivalents which will be side installed--can you remove those "included applications"?--by the die hard OSS people--go figure why they'd buy an MS Surface Tablet...--are allowed to take up gobs of space too. Seriously, though, this is one reason I'm still not sold on tablets in general--beyond all the ways they're generally inferior to a laptop for lacking a keyboard; the storage capacity isn't reasonably there for one's music/movie collection. But, then, I'm the sort of person who wants to buy a NewsRadio collection, rip it to disk, and then be able to play it anywhere on my shiny new tablet without (a) reencoding it down just for the tablet or (b) considering buying a separate SD card just for it (or it and one other thing). HDs are still king for storage and just not a good idea for tablets. So, I think the world is reasonably at an impasse for at least a few years until internal storage capacity doubles a few more times. Ie, the year of the tablet may actually be at hand and not just a fun fad. :/
Given your statement aobout companies being rat bastards, why would you believe they even *have* encrypted database tables? And if they do, what are the odds the key is stored on the same machine--ie, they only encrypted the table due to some contract specifying it but the contract failed to exclude the obvious "and the key can't be on the same machine"? But, yea, most companies are likely to try to downplay the risk.
That's a good thing if it's for the tax man--you can report an operating loss. And it's a bad thing to tell shareholders--who want the paper value of the company to go up. Never the less, if the company has an dollar loss as a result of a hack, why wouldn't they tell it? As for the hypothetical lost value from lost data? You report to shareholders the lost data and the potential lost value, both best case and worst case and an argument on how you think things will play out and why. Ie, you simply try your best to inform them because...tada..they're the owner(s) and deserve no less.
Um..is the discussion really about mailing an envelope to everyone potentially effected every time? Or is it to (a) include a report in the quarterly stockholder information you're already handing out and (b) handing a report to the SEC (and maybe the media, if appropriate) to allow them to disseminate the information to the broader community?
And the question then becomes, and at what point is this not just fraud? If a company finds out the food they shipped out may be contaminated, they may *want* to sweep it under the rug, but to do so is most often simply illegal under various regulations. But without even the regulations, for a company to continually and knowingly to misrepresent itself just to not "spook your investors"? That's not how the world works. The only thing you can do is to try to spin the facts as best you can to adequately prepare those investors so they aren't overly spooked. But if there's a data breach and there's reason to be spooked, no amount of spin will or should help you.
In the end, as you say, it comes down to what "they should [do] but they won't". The real question is what, if anything, should be done on the societal, investor, and/or governmental end. The point that another poster raised, that most people shouldn't be investing in the stock market is quite cogent to this point. Society as a whole won't punish bad companies, generally. Government is too often too slow to act to have much effect--unless it's a long-term pattern of abuse. The only real recourse then is enough investor involvement, not simply to make a buck but to be involved enough to replace managers and CEOs who are so inclined to "sweep it under the rug". This also means working more towards making sure future data breaches are less likely to happen. But, even under such a scheme it's far from perfect, as enough big time speculators can game, manipulate, etc the stock market--and there's a long history of it in the past--which makes the idea of an investor driven stock market perhaps more of a pipe dream than a reality, anyways.
Considering how much Republicans (and I imagine most rich Democrats) hate the Estate Tax...
Seriously, though, the humor to me of it all is how the argument for why Estate taxes are so evil--that they take away a life time of effort and simply hand it over to a government that didn't earn it like the person did. Well, people, you can't take your money to your grave. That gold ring on you finger won't look too pretty on your rotting body or eventually your brittle skeleton. When you're dead, you're dead.
Besides, the idea of being able to hand out big chunks of estate to people of your choosing really goes against the whole idea of equal opportunity when those gifts are given to children, grandchildren, etc. Meanwhile, one can give tax exempt gifts of scholarship, medical payments, *cough* political organizations, and tax deductible gifts--which go against the idea of equal opportunity but at least don't seem focused on simply allowing for self-supporting dynasties.
Really, I think it all comes down to the fact that I've never heard of a solid explanation on how property can come into ownership into the first place--simply saying "me first" is an absurd justification given just minimally that there's no way to really know if you're first. Nor is there a solid explanation on how property can be properly abandoned--be it through natural death or murder--not unlike the issue of whether a copyrighted work can sensically be put into the public domain. In the end, it's all a level of arbitrary government sanctioned rules. And once you're at that point, then the Estate Tax or a Gift Tax make as much sense as anything else.
Security theatre works some times because some criminals are (a) stupid enough to believe it's real and/or (b) stupid enough to be caught by the very bad security actors. As for what's wrong with it, how about that it treats 100% of the populace as very potential criminals and is generally creepy?
Oh, I don't know... Perhaps it has something to do with CCTVs are like locks, they help keep honest people honest (ie, they work to keep the already low crime rate marginally lower); meanwhile, constantly tracking overwhelming honest people in public spaces is very dickish. So, hey, it might well be perfectly legal to do. That doesn't mean I really want to do business with dicks.
No, that's the wrong book. You want something closer to It Can't Happen Here. Of course, the truth is the whole government involvement isn't needed when enough companies go along with it and enough people are complicit in letting it happen. The funniest part is that "for the children" is almost certainly the excuse. "For the children" is how smutty or even semi-smutty magazines were banned from the shelves--yet still available behind the counter. Meanwhile, "for the children" is used to justify CCTV to catch potential creepy perps running off with their kids--a very uncommon thing--and meanwhile it ignores that CCTV can be constantly used by creepy perps to stare at their kids--made even creepier with the whole TSA body scanners.
In short, it really comes down to priorities and who people place their faith in. What Creepy Cameraman really proves is that no matter what, there's a person behind the camera and they could be just as creepy as he is. So, it's hard for me to place a lot of faith in CCTVs as a general point. :/
I don't really disagree, but then that's paramount to promoting theft--and something I don't think most companies would openly admit to. :) And the UK, of course, takes it to the extreme and tries to make it "steal from the [country] down the [channel] rather than [us]", which is obviously absurd. But, then, that's why I call it all security theater. But, then, in the UK, I guess that'd be security theatre...