Fortunately, 'apt-get install great-program' always works for me.
Talk about a flawed model. Instead of dealing with the problem (reference management), Linux repositories sweeps the problem under the rug.
Instead of coming up with a solution which can actually *both* allow shared libraries to be used *and* support a heterogeneous software environment, Linux repositories forces an artificially homogeneous environment.
Instead of a software package supporting d distros and v versions by virtue of an OS supported library broker, you are forced to create d*v versions of the software package. This is the reasons so many drivers and applications break between versions: Nobody can test every distro and every (supported) version of every distro. The software authors typically will only test a few of the most popular distros and often only the most recent version. Compatibility errors crop up, but the exercise of finding them is left to the users.
The basic idea of a software repository with signed packages is sound. (Mis)using software repositories by cloning them to address the problem with dependency hell is stupid. The model does not scale. And it *still* does not solve the problem. Step outside of the distro and version specific (!) software repository and you are back in dependency hell, knee-deep. Software repositories are the Matrix. It is a dream world that has been created to disguise the ugly problem which still exists in Linux: Dependency hell.
Contrary to the ignoramuses still beating the DLL hell drums, the problem has been solved the right way in Windows: Side by side assemblies (SxS). From "Windows Internals":
Fusion (SxS) Redirection. Fusion (also referred to as side-by-side, or SxS) is an extension to the Windows application model that allows components to express more detailed binary dependency information (usually versioning information) by embedding binary resources known as manifests. The Fusion mechanism was first used so that applications could load the correct version of the Windows common controls package (comctl32.dll) after that binary was split into different versions that could be installed alongside one another; other binaries have since been versioned in the same fashion. As of Visual Studio 2005, applications built with the Microsoft linker will use Fusion to locate the appropriate version of the C runtime libraries.
Basically, as an application developer you have two choices which both avoid dependency hell: Ship the specific version of the DLL with your application (but do *not* install in Windows/System32) or request the installer installs the DLL as a SxS assembly and then reference it from your application manifest. The SxS cache can hold multiple versions of the same DLL and the manifest can describe the policy for brokering the version (whether the app always wants the latest or a specific version, for instance). This allow patching to be performed on the central SxS cache instead of each application with separate libraries.
There is a reason GP has not experienced "DLL nightmare". It doesn't exist any more. These days it is but a myth that detractors desperately want to keep alive.
Fair enough. So you seem to think that C#s implementation does not go *far* enough - that it is *lacking* features. I would also like to see proper currying and more functional constructs. I also would like trais. However, language design is not the discipline of cramming in every potential useful feature you can think of.
Proper language design also has a very important pragmatic dimension: How will the feature be used, what is the balance between the complexity it introduces and the value it will add to the domain that is targeted by the language.
That is a legitimate discussion, and frankly, my book is still open on generics variance. While I believe that I understand it, I can tell you that there are a lot of developers who simply avoid the topic because it is complex and hard to wrap your head around.
In the case of generics I believe that it is a conscious decision. Microsoft/Anders Hejlsberg have on several occasions stated that they do *not* add features unless it is driven by some very specific use case that will demonstrably ease development (directly or indirectly) for the majority of users. Java language designers have also been cautious (perhaps too much), but where they have not, the experience should be a warning. Nowhere is that more evident than with checked exceptions. That *exactly* is an example of a language feature which is theoretically correct (if a little verbose and cumbersome), but when tested in real life with real programmers falls flat.
In other words: I don't buy your premise that because *you* believe that some feature should have been implemented, then somehow the language is "poorly implemented". Frankly, that is a elitist and somewhat ignorant position, and I hope the language designers of both Java and C# have more sense than that.
The primary responsibility og language designers when opting to *not* implement a specific feature (e.g. higher order generics) is to not *prevent* it from being implemented at some later point in time. That would be "poorly implemented".
It is in that sense that Javas generics are "poorly implemented": They way they have been implemented precludes them from becoming real reified generics in the future, and the problems with type erasure are real, not least evidenced by the problems designing and implementing lambda expressions in Java 8 (btw, *exactly* because of a combination of type erasure and checked exceptions Java 8 will still not have real closures).
C# generics started out with generics without variance. Only in the next version were proper define-site variance cautiously implemented. But C# also has design mistakes (that I believe Anders Hejlsberg would readily admit), like e.g. variant arrays (impedance mismatch with collections), the delegate syntax for anonymous methods (since superceded by the more expressive lambda expression syntax), nullability (why are reference types always implicitly nullable?).
Well, to be fair, generics are also poorly implemented in C#. If scala can use higher order generics like Haskell can, there's no reason why C# and Java shouldn't be able to.
I'm curious. C# avoided the stupid type-erasure mistake (one that has come back to bite Java, *especially* during the Lambda-J discussions). C# has define-site variance as opposed to use-site variance. What exactly is your problem with C# generics?
Re:After years of saying java didn't need C# featu
on
Love and Hate For Java 8
·
· Score: 3, Informative
Right, lets pretend Microsoft invented all of those things.
If you had been following the language discussions for (for instance) lambda-J you would realize that there is a LOT more to it than simply deciding that a language must have this or that feature.
Specifically, both Java and C# are statically typed languages (although in C# a variable can be statically typed to be dynamic, but I digress) with advanced multi-generation garbage collection, structured exception handling, generics etc. Any new concepts introduced into the language must respect the concepts already there. Designing new features for Java or C# requires significant amount of innovation to solve the interference problems and maintaining the "feel" of the language.
LINQ is a real accomplishment, one that I have not seen put together like that in any other language. Yes, list comprehensions existed before. Yes, expression trees (ASTs) have been used in LIST and several other languages before. Don't know about extension methods, but I'm sure that there must be some research language. Yes, type inference had been used before. Yes, inferred classes must have been used in some language before. Certainly lifted types are well-known in certain other languages. But putting the whole package together and make it fit seamlessly with (and complement) the existing features and at the same time keep it so simple and generic that the useful parts are actually library features, that is a real accomplishment.
Reactive Extensions is real research (primarily by Erik Meijer who has regrettably now left Microsoft to return to academia). Not least because it ties to beautiful in with LINQ. It is entirely new? No, as Erik himself would say, IEnumerable is just a monad. IMHO that does not take away from the accomplishment.
Async and await are *really* cool and have inspired Scala to create something similar.
No, Microsoft didn't invent "all of those things". But fitting them in with a curly-brace, statically typed language is real innovation.
My solution on windows is to take some of the directories with 10,000 files and put them into an archive (think clipart directories).
I hope your are not an IT professional. Windows comes with a perfectly good backup solution built-in. It will use Volume Shadow Copy Service (VSS) to track changes as they occur and subsequently only do backup of the changes blocks. No need to scan *anything* as the journaling file system has already recorded a full list of changes in the journal.
The backup is basically stored in a VHD virtual harddisk (and some catalog metadata around it), so you can even attach the VHD and browse it. It will by default let you browse the latest backup, but the previous versions feature will let you browse back in time to any previous backup still stored in the VHD (oldest backups vill be pruned from the backup when the capacity is needed). The VHD is a inverse incremental backup because it stores the latest backup as the readily available version and only the incremental (block level) differences between previous backup sets.
Moreover, VSS also ensures persistent consistency for a lot of applications that are VSS aware (VSS writers), i.e. database systems like Oracle, SQL Server, Active Directory, registry etc. VSS coordinates with the applications so that exactly when the snapshot is taken, the applications ensure that they have flushed all state to disk. This means that applications will not need to be stopped to get a consistent backup, i.e. database systems will not see a restore of a backup that was taken from a running system as a "crash" (as they would without such a service) from which they must recover through some other means (typically a roll-forward log).
Unless you're running Windows 8 or Server 2012, Windows Backup on Windows 7 and below is functionally obsolete due to the new 3TB + drives now in 4k sector Advanced Format technology.
Nice. So because you can buy large-capacity drives that immediately would "functionally obsolete" backup solutions even if a system does not have such a drive? Tell me, did you buy a new BMW when apple changed the connector for iPhone 5? You know, the old BMW are now "functionally obsolete".
Not that it matters much here anyway, because you got it wrong. Windows backup *will* backup to drives larger than 3TBs - as long as they use the 512e advanced formatting where it logically uses 512 bytes allocation units but physically 4096 bytes units. The solution is to use the GPT (GUID Partition Table) format. This will work for Vista and up.
The drives that are exclusively 4096 cannot be used with Windows 7 / Server 2012 - that's a limitation of the OS and not the backup software, however.
You can use it for automation sure, but out of the box it does not do any. Nearly no windows user will know how to use that. It would need a shiny wizard and other mythical figures to do that for you.
My personal favorite is to have bacula do it, that is even less end user friendly though. It does mean all the schedules live on the server not the client, which is nice.
I have this feeling that if I had shown you the GUI part first, you would have dismissed that as "not automation". Hence, I chose to point out the wbadmin.exe tool.
BTW, wbadmin.exe *is* "in-box". So your assertion "but out of the box it does not do any" is false. And yes, you can *also* set up daily scheduled backup with the GUI. It will actually create a task in task scheduler which uses (surprise!) wbadmin.exe!
Home versions of windows don't support scheduled backups. You might be able to hack something yourself using task scheduler and a batch file though.
No, that is not correct.
At least in Windows 7 *all* editions have the full image capability. Only the professional/enterprise editions can backup to a *network* drive. But in this case it is a local or attached disk, so the edition really does not matter.
Windows Backup (since Vista) use Volume Shadow Copy (VSS) to do block level reverse incremental backup. I.e. it uses the journaling file system to track changed Blocks and only copies over the changed Blocks.
Not only that, it also backs up to a virtual harddisk file (VHD) which you can attach (Mount) as a seperately. This file system will hold the complete history, i.e. you can use the "previous versions" feature to go back to a specific backup of a directory or file.
"One full-time Java programmer told me that he hasn’t had to manually type in any setters and getters in years, and he has a template from which all his objects are typed in automatically, thanks to the code snippet tools in his favorite editor (which isn’t Eclipse—he uses IntelliJ). Clearly, methods of automated typing seem to be a favorite among a lot of programmers. So why did Visual Studio remove a feature that facilitated this? Who knows."
Let's not mention the fact that in C# you don't need to manually type in all the getter/setter junk, just public int MyField {get; set;}
Of course, the "one developer" is heavily biased towards Java (his previous articles were outrageous) and probably *do not know* that snippets exists in Visual Studio because he has never use VS in any professional capacity.
If Secunia is correct that the root cause is a use-after-free vulnerability, it exploitability is likely not limited to simple DOS. Secunia talk about a callback handler. A use after free vulnerability can easily lead to execution of arbitrary code, depending on how much control the artacker can assert over the memory.
Also, it is interesting if the sentiment is that it is not a vulnerability if it sits in a linked library. Should it really be considered a vulnerability of the library and not of the product using the library? For all intents and purposes, it is a vulnerability of the product.
The concept is solid enough, but the implementation is flawed. As a consequence of mandating that the factory burns in the signing key, it pretty much forces MS to sign competitor payload or be seen as anti-competitive.
This is where you fail. Microsoft does not sign competitor payload using a UEFI burned key. What Microsoft offers is that they will sign 2nd level boot loaders so that the Microsoft bootloader will accept to chain-load it. You cannot directly boot such a Microsoft signed bootloader or OS directly from UEFI.
Why is this significant? Because 1. It allows Microsofts bootload'er to make it *obvious* that a foreign OS is being booted. You cannot get around this because it is Microsofts code that gets the control before your code. 2. It allows Microsoft to *revoke* that specific signing if it turns out that it is being used for nefarious purposes.
This means your Microsoft install implicitly trusts software from Red Hat, Canonincal, VMware, Attachmate, and really anyone else who may enter the ring. There is no way that MS is providing adequate auditing to assure those paths aren't vulnerable and it shouldn't have to. Because it must be installed into firmware before an OS touches it, there is also *no* reasonable opportunity to provide any assurance of customer provided content like configuration.
Again, fail. The key validating software from Linux vendors (when they use Microsofts boot loader shim) is NOT in the firmware. It is part of Microsofts bootload'er (which is in turn validated by UEFI). If a 2nd level bootloader shim is being used for nefarious purposes, Microsoft can *revoke* that specific bootloader/OS. Thus, it is in the self-interest of distros to secure their part of the path.
As to that root kit you mentioned, MS could have protected itself from that without SecureBoot or any boot signing. MS could have made MBR writes from within their OS forbidden without an extreme warning. No OS bothers to do that, but it would have been actually a pretty defensible move on their part to mitigate root kits.
Defense in depth. Secure boot cannot prevent vulnerabilities, nor is it designed to do that. It is designed to prevent malicious code from gaining persistent foothold on a system, i.e. a guaranteed validated system after each boot. A kernel space exploit in any OS can lead to the attacker can write to otherwise off-limit areas. I trust that you are not advocating hard-shell-soft-core security.
The problem is that Secure Boot gives MS control of the entire ecosystem but in doing so missed an opportunity to provide something that *would* have worked better and allowed MS to avoid vouching for anything but their own software at boot time.
Linux Foundation could have stepped up as signing authority. Or Red Hat - they have the amp to do so. As it happens, both those organizations actively declined. There is *nothing* in UEFI that precludes anyone else from having their keys directly in the firmware. They would need to work with multiple vendors, however. That's why it would have been a job for LF or Red Hat.
Incidentally, Microsoft Hyper-V 3 (launches with Server 2012R2) support secure boot and has UEFI firmware. And yes, you can register your own keys. If VMWare/Xen/KVM were to offer the same this will soon become a silly discussion as this would pertain only to the lowest level hypervisor layer on a host. I could certainly fathom VMWare working with server vendors to have *their* key pre-registered.
My issue is that I'm having a hard time seeing what SecureBoot adds that cannot be acheived in a better fashion (e.g. more comprehensive use of a TPM). SecureBoot doesn't ensure that your are booting is signed by someone you trust.
Yes it does. Especially on Windows, the OS is booted from signed cabinet files, i.e. the Microsoft bootloader will refuse to boot Windows unless the cabinet file (which include executables, libraries, core config files) is signed correctly.
It assures that one efi executable was signed by someone (who you may or may not 'trust'), but most would conceive of 'what you are booting' to be the universe of everything that happens prior to the system being usable, boot loader, kernel, configuration, third party executables, etc etc,
And if the bootloader and OS in turn takes on their part of that responsibility, you *do* have a trusted chain. Of course, it requires that the OS is booted from signed files that include executables as well as config. If the OS is set to require signatures (or hash matches) of 3rd party executables it can ensure integrity for itself. The chain merely ensures that each step can be confident that at the time where each step receives control of the system, integrity is ensured. Each step must ensure it's own integrity and only pass control to the next step if integrity can be validated.
Because it fits the description and was confirmed by Microsofts Shaw as such (one of two programs) in the original Bloomberg article.
The question is this: Why would *you* think otherwise?
It's highly likely that NSA gets this information way before any one from the MAPP program does
Why? Citation needed.
it's also feasible to speculate that NSA could tell Microsoft to hold certain patches for a specific time period.
Do you make this up as you go? Is that tin foil hat uncomfortable? Pure FUD.
Yes, it is likely that the NSA have made requests like that. It is *highly* likely that Microsoft have *rejected* such requests, given that 1) they are not required under any law to grant such requests and 2) granting such requests could seriously damage trust in their products.
Now your going out on a limb. Stuxnet infected industrial machines (Siemens I believe) - not windows.
Wrong. Stuxnex infected Windows machines used to *control* industrial machines. It indeed infected Windows, but it only delivered it's payload when it had infected a Windows machine connected to specific Siemens equipment.
The "magical backdoor" is just an private key for signing windows modules as "trusted".
Minor correction: The _NSAKEY is a public key, the private part of which can be used to sign *cryptographic providers*. Windows will not accept just any cryptographic provider to be installed; it must be signed with one of the two built-in keys, one of which is the _NSAKEY. The key itself does not allow automatic installation, it is a way to avoid being *rejected* by Windows.
One can speculate why there is a special signing regime for crypto providers. However, there is a hint in the fact that the infamous key was found in a version of Windows that belonged to a time at which crypto algorithms bit bit sizes above 40 bits were considered class B weapons!
All windows machines accept any module as trusted if it is signed with that key.
Nope. Just cryptographic providers. And you must still explicitly *install* them. The they does not magically open up a backdoor to the internet and allow Microsoft or NSA to install "any module". And you don't need a crypto provider to compromise a system. A kernel mode driver will do.
Bruce Scheier or others in his field assume such keys to be under the protection of Microsoft and therefore "safe" (i.e. not a back door for loading malicious spy modules onto any windows machine - which any agency can do when they have access to the key/s).
Again, no. The key does not magically allow any agency to execute code on your or anyone else's Windows machines. The key can be used to avoid having a crypto provider rejected on installation.
if Microsoft giving NSA info on undisclosed vulnerabilities, they have in effect a magic backdoor in Windows.
Would you prefer that Microsoft tells foreign companies about vulnerabilities *without* informing the NSA about the same vulnerabilities?
The MAPP program is public and has been since it's introduction. As part of the program, Microsoft will release vulnerability information (and sometimes even PoC exploit code) to MAPP partners a few days in advance of releasing the patch for a vulnerability.
The reason is that a vulnerability patch is essentially the same as a disclosure. It is in the interest of both Microsoft, AV vendors and Microsofts' customers that AV vendors get a head start when creating scanning signatures that will catch exploit attempts.
Some of these AV vendors are foreign companies. Yes, some of them may be shells for or cooperate with e.g. a foreign intelligence service. Yes, even if they are only given a head start of a few days, there certainly is a risk that a foreign intelligence body could use the information to infiltrate US companies or government entities.
In that light, is it so terrible that the NSA get the information as well? You know, it could actually deter the foreign entity from actually attempting an exploit.
This is a fabricated scandal. Worse, it detracts from the *real* scandal, which is not what companies have been forced to hand over but rather the erosion of rights in the law.
The fact that almost no one knows about this menu is foolish... and a hint to what Microsoft has done wrong. I only found out about that menu because of tutorial software that ASUS ships on its Win8 notebooks.
No, it is proof that slashdot is full of ignorant and irrational Microsoft haters who take great pleasure in ranting about made-up problems they have never actually experienced themselves.
HLSL shader linking Inbox HLSL compiler GPU overlay support DirectX tiled resources Direct3D low-latency presentation API DXGI Trim API and map default buffer Frame buffer scaling Multithreading with SurfaceImageSource Interactive Microsoft DirectX composition of XAML visual elements Direct2D batching with SurfaceImageSource
IMHO the big one is probably tiled resources. Think minecraft world virtually on the graphics card. From the applications perspective that it how it controls the graphics card. The app then also provides services for the graphics engine to request tiles with given scale at demand.
mysqldump? But what you are doing, i.e backup of the database files directly, is a very dangerous form of backup. Restoring such when the database has been corrupted for whatever reason
Actually no, it is not dangerous provided that you use a backup agent or an operating system that supports this. Windows does, Linux and Unix do not.
On Windows the Volume Shadow Copy Service (VSS) will interact with registered processes to coordinate *when* they should ensure persistent consistency - which is reserved as a fraction of a second. It requires the processes to register as VSS writers - which database servers generally do (Oracle and SQL Server do - I do not know if MySQL does).
On Windows in a virtual environment this will even propagate through VM volumes, i.e. if you backup the host of the VMs (where some of the VMs could be running database servers), the host VSS service will ask the guest VSS service to ensure consistency right when the disk image file is being backed up. This means that you can backup the host Hyper-V server with all the disk images and rest assured that the VMs are consistent.
Why would the score be higher for a server build? What use would a server have for a web browser? Surely they should be making more effort on the client version of the browser, where it might actually be used?
It is the same version, but running on the server it may disable some features because of security settings. Actually I'm surprised that WebGL is enabled on a server build, given that WebGL has the potential to inject and run code on your GPU.
However, there needs to be a server version for 1) those who install and maintain a server through it's own GUI and 2) servers used as "terminal servers". Yes, 1) is bad practice but it actually allows small shops to run their own server. Microsoft recommends installing servers as "server core" - i.e. with no GUI.
Does it not mean that the NSA can validly sign executables or libraries? It might not have a listening socket but the principles are the same.
Even if the private key belongs to the NSA (which is *extremely* unlikely - read Bruce Sneiers opinion) it would only mean that the NSA could sign *cryptographic providers*. It does not open any backdoor for the NSA to install software on your computer. The key is used to ensure that not just any cryptographic provider can be installed; it needs to be signed by Microsoft. You would still need to actually *install* the crypto provider. They signing would be used to ensure that it was not rejected by Windows.
If the NSA has a way to trick you into installing a crypto provider, you have bigger concerns than that. You do not need to install a crypto provider to pwn a system. Any system, any OS.
The key is from a time where cryptography was actually classified as weapons class B - and had export restrictions. At the time they could only ship with 40 bit (symmetric) keys. Too strong encryption would allow foreign entities to encrypt communication without the NSA being able to brute-force it. Those restrictions have since then been lifted as they were obviously stupid and only hurt US exports. Anyone who needed to encrypt messages with stronger keys would just use another product - even on Windows.
That said, the NSA is free to obtain an Authenticode certificate and sign executables just like anyone else.
Slashdot Mirror
Fortunately, 'apt-get install great-program' always works for me.
Talk about a flawed model. Instead of dealing with the problem (reference management), Linux repositories sweeps the problem under the rug.
Instead of coming up with a solution which can actually *both* allow shared libraries to be used *and* support a heterogeneous software environment, Linux repositories forces an artificially homogeneous environment.
Instead of a software package supporting d distros and v versions by virtue of an OS supported library broker, you are forced to create d*v versions of the software package. This is the reasons so many drivers and applications break between versions: Nobody can test every distro and every (supported) version of every distro. The software authors typically will only test a few of the most popular distros and often only the most recent version. Compatibility errors crop up, but the exercise of finding them is left to the users.
The basic idea of a software repository with signed packages is sound. (Mis)using software repositories by cloning them to address the problem with dependency hell is stupid. The model does not scale. And it *still* does not solve the problem. Step outside of the distro and version specific (!) software repository and you are back in dependency hell, knee-deep. Software repositories are the Matrix. It is a dream world that has been created to disguise the ugly problem which still exists in Linux: Dependency hell.
Contrary to the ignoramuses still beating the DLL hell drums, the problem has been solved the right way in Windows: Side by side assemblies (SxS). From "Windows Internals":
Basically, as an application developer you have two choices which both avoid dependency hell: Ship the specific version of the DLL with your application (but do *not* install in Windows/System32) or request the installer installs the DLL as a SxS assembly and then reference it from your application manifest. The SxS cache can hold multiple versions of the same DLL and the manifest can describe the policy for brokering the version (whether the app always wants the latest or a specific version, for instance). This allow patching to be performed on the central SxS cache instead of each application with separate libraries.
There is a reason GP has not experienced "DLL nightmare". It doesn't exist any more. These days it is but a myth that detractors desperately want to keep alive.
Fair enough. So you seem to think that C#s implementation does not go *far* enough - that it is *lacking* features. I would also like to see proper currying and more functional constructs. I also would like trais. However, language design is not the discipline of cramming in every potential useful feature you can think of.
Proper language design also has a very important pragmatic dimension: How will the feature be used, what is the balance between the complexity it introduces and the value it will add to the domain that is targeted by the language.
That is a legitimate discussion, and frankly, my book is still open on generics variance. While I believe that I understand it, I can tell you that there are a lot of developers who simply avoid the topic because it is complex and hard to wrap your head around.
In the case of generics I believe that it is a conscious decision. Microsoft/Anders Hejlsberg have on several occasions stated that they do *not* add features unless it is driven by some very specific use case that will demonstrably ease development (directly or indirectly) for the majority of users. Java language designers have also been cautious (perhaps too much), but where they have not, the experience should be a warning. Nowhere is that more evident than with checked exceptions. That *exactly* is an example of a language feature which is theoretically correct (if a little verbose and cumbersome), but when tested in real life with real programmers falls flat.
In other words: I don't buy your premise that because *you* believe that some feature should have been implemented, then somehow the language is "poorly implemented". Frankly, that is a elitist and somewhat ignorant position, and I hope the language designers of both Java and C# have more sense than that.
The primary responsibility og language designers when opting to *not* implement a specific feature (e.g. higher order generics) is to not *prevent* it from being implemented at some later point in time. That would be "poorly implemented".
It is in that sense that Javas generics are "poorly implemented": They way they have been implemented precludes them from becoming real reified generics in the future, and the problems with type erasure are real, not least evidenced by the problems designing and implementing lambda expressions in Java 8 (btw, *exactly* because of a combination of type erasure and checked exceptions Java 8 will still not have real closures).
C# generics started out with generics without variance. Only in the next version were proper define-site variance cautiously implemented. But C# also has design mistakes (that I believe Anders Hejlsberg would readily admit), like e.g. variant arrays (impedance mismatch with collections), the delegate syntax for anonymous methods (since superceded by the more expressive lambda expression syntax), nullability (why are reference types always implicitly nullable?).
Well, to be fair, generics are also poorly implemented in C#. If scala can use higher order generics like Haskell can, there's no reason why C# and Java shouldn't be able to.
I'm curious. C# avoided the stupid type-erasure mistake (one that has come back to bite Java, *especially* during the Lambda-J discussions). C# has define-site variance as opposed to use-site variance. What exactly is your problem with C# generics?
Right, lets pretend Microsoft invented all of those things.
If you had been following the language discussions for (for instance) lambda-J you would realize that there is a LOT more to it than simply deciding that a language must have this or that feature.
Specifically, both Java and C# are statically typed languages (although in C# a variable can be statically typed to be dynamic, but I digress) with advanced multi-generation garbage collection, structured exception handling, generics etc. Any new concepts introduced into the language must respect the concepts already there. Designing new features for Java or C# requires significant amount of innovation to solve the interference problems and maintaining the "feel" of the language.
LINQ is a real accomplishment, one that I have not seen put together like that in any other language. Yes, list comprehensions existed before. Yes, expression trees (ASTs) have been used in LIST and several other languages before. Don't know about extension methods, but I'm sure that there must be some research language. Yes, type inference had been used before. Yes, inferred classes must have been used in some language before. Certainly lifted types are well-known in certain other languages. But putting the whole package together and make it fit seamlessly with (and complement) the existing features and at the same time keep it so simple and generic that the useful parts are actually library features, that is a real accomplishment.
Reactive Extensions is real research (primarily by Erik Meijer who has regrettably now left Microsoft to return to academia). Not least because it ties to beautiful in with LINQ. It is entirely new? No, as Erik himself would say, IEnumerable is just a monad. IMHO that does not take away from the accomplishment.
Async and await are *really* cool and have inspired Scala to create something similar.
No, Microsoft didn't invent "all of those things". But fitting them in with a curly-brace, statically typed language is real innovation.
My solution on windows is to take some of the directories with 10,000 files and put them into an archive (think clipart directories).
I hope your are not an IT professional. Windows comes with a perfectly good backup solution built-in. It will use Volume Shadow Copy Service (VSS) to track changes as they occur and subsequently only do backup of the changes blocks. No need to scan *anything* as the journaling file system has already recorded a full list of changes in the journal.
The backup is basically stored in a VHD virtual harddisk (and some catalog metadata around it), so you can even attach the VHD and browse it. It will by default let you browse the latest backup, but the previous versions feature will let you browse back in time to any previous backup still stored in the VHD (oldest backups vill be pruned from the backup when the capacity is needed). The VHD is a inverse incremental backup because it stores the latest backup as the readily available version and only the incremental (block level) differences between previous backup sets.
Moreover, VSS also ensures persistent consistency for a lot of applications that are VSS aware (VSS writers), i.e. database systems like Oracle, SQL Server, Active Directory, registry etc. VSS coordinates with the applications so that exactly when the snapshot is taken, the applications ensure that they have flushed all state to disk. This means that applications will not need to be stopped to get a consistent backup, i.e. database systems will not see a restore of a backup that was taken from a running system as a "crash" (as they would without such a service) from which they must recover through some other means (typically a roll-forward log).
Unless you're running Windows 8 or Server 2012, Windows Backup on Windows 7 and below is functionally obsolete due to the new 3TB + drives now in 4k sector Advanced Format technology.
Nice. So because you can buy large-capacity drives that immediately would "functionally obsolete" backup solutions even if a system does not have such a drive? Tell me, did you buy a new BMW when apple changed the connector for iPhone 5? You know, the old BMW are now "functionally obsolete".
Not that it matters much here anyway, because you got it wrong. Windows backup *will* backup to drives larger than 3TBs - as long as they use the 512e advanced formatting where it logically uses 512 bytes allocation units but physically 4096 bytes units. The solution is to use the GPT (GUID Partition Table) format. This will work for Vista and up.
The drives that are exclusively 4096 cannot be used with Windows 7 / Server 2012 - that's a limitation of the OS and not the backup software, however.
You can use it for automation sure, but out of the box it does not do any. Nearly no windows user will know how to use that. It would need a shiny wizard and other mythical figures to do that for you.
My personal favorite is to have bacula do it, that is even less end user friendly though. It does mean all the schedules live on the server not the client, which is nice.
I have this feeling that if I had shown you the GUI part first, you would have dismissed that as "not automation". Hence, I chose to point out the wbadmin.exe tool.
BTW, wbadmin.exe *is* "in-box". So your assertion "but out of the box it does not do any" is false. And yes, you can *also* set up daily scheduled backup with the GUI. It will actually create a task in task scheduler which uses (surprise!) wbadmin.exe!
Home versions of windows don't support scheduled backups. You might be able to hack something yourself using task scheduler and a batch file though.
No, that is not correct.
At least in Windows 7 *all* editions have the full image capability. Only the professional/enterprise editions can backup to a *network* drive. But in this case it is a local or attached disk, so the edition really does not matter.
It totally lacks automation, which is a pretty big downside.
wbadmin.exe is available since Vista (where the VSS based image backup was introduced).
How is that totally lack of automation?
Windows Backup (since Vista) use Volume Shadow Copy (VSS) to do block level reverse incremental backup. I.e. it uses the journaling file system to track changed Blocks and only copies over the changed Blocks.
Not only that, it also backs up to a virtual harddisk file (VHD) which you can attach (Mount) as a seperately. This file system will hold the complete history, i.e. you can use the "previous versions" feature to go back to a specific backup of a directory or file.
"One full-time Java programmer told me that he hasn’t had to manually type in any setters and getters in years, and he has a template from which all his objects are typed in automatically, thanks to the code snippet tools in his favorite editor (which isn’t Eclipse—he uses IntelliJ). Clearly, methods of automated typing seem to be a favorite among a lot of programmers. So why did Visual Studio remove a feature that facilitated this? Who knows."
Let's not mention the fact that in C# you don't need to manually type in all the getter/setter junk, just public int MyField {get; set;}
Yep. And let's also not mention the fact that VS2012 *does* have snippets: http://msdn.microsoft.com/en-us/library/vstudio/ms165392.aspx
Of course, the "one developer" is heavily biased towards Java (his previous articles were outrageous) and probably *do not know* that snippets exists in Visual Studio because he has never use VS in any professional capacity.
What if the library is statically linked (as it is on some platforms with VLC as I understand it)? Then it is distributed with the product.
(original submitter here)
If Secunia is correct that the root cause is a use-after-free vulnerability, it exploitability is likely not limited to simple DOS. Secunia talk about a callback handler. A use after free vulnerability can easily lead to execution of arbitrary code, depending on how much control the artacker can assert over the memory.
Also, it is interesting if the sentiment is that it is not a vulnerability if it sits in a linked library. Should it really be considered a vulnerability of the library and not of the product using the library? For all intents and purposes, it is a vulnerability of the product.
The concept is solid enough, but the implementation is flawed. As a consequence of mandating that the factory burns in the signing key, it pretty much forces MS to sign competitor payload or be seen as anti-competitive.
This is where you fail. Microsoft does not sign competitor payload using a UEFI burned key. What Microsoft offers is that they will sign 2nd level boot loaders so that the Microsoft bootloader will accept to chain-load it. You cannot directly boot such a Microsoft signed bootloader or OS directly from UEFI.
Why is this significant? Because
1. It allows Microsofts bootload'er to make it *obvious* that a foreign OS is being booted. You cannot get around this because it is Microsofts code that gets the control before your code.
2. It allows Microsoft to *revoke* that specific signing if it turns out that it is being used for nefarious purposes.
This means your Microsoft install implicitly trusts software from Red Hat, Canonincal, VMware, Attachmate, and really anyone else who may enter the ring. There is no way that MS is providing adequate auditing to assure those paths aren't vulnerable and it shouldn't have to. Because it must be installed into firmware before an OS touches it, there is also *no* reasonable opportunity to provide any assurance of customer provided content like configuration.
Again, fail. The key validating software from Linux vendors (when they use Microsofts boot loader shim) is NOT in the firmware. It is part of Microsofts bootload'er (which is in turn validated by UEFI). If a 2nd level bootloader shim is being used for nefarious purposes, Microsoft can *revoke* that specific bootloader/OS. Thus, it is in the self-interest of distros to secure their part of the path.
As to that root kit you mentioned, MS could have protected itself from that without SecureBoot or any boot signing. MS could have made MBR writes from within their OS forbidden without an extreme warning. No OS bothers to do that, but it would have been actually a pretty defensible move on their part to mitigate root kits.
Defense in depth. Secure boot cannot prevent vulnerabilities, nor is it designed to do that. It is designed to prevent malicious code from gaining persistent foothold on a system, i.e. a guaranteed validated system after each boot. A kernel space exploit in any OS can lead to the attacker can write to otherwise off-limit areas. I trust that you are not advocating hard-shell-soft-core security.
The problem is that Secure Boot gives MS control of the entire ecosystem but in doing so missed an opportunity to provide something that *would* have worked better and allowed MS to avoid vouching for anything but their own software at boot time.
Linux Foundation could have stepped up as signing authority. Or Red Hat - they have the amp to do so. As it happens, both those organizations actively declined. There is *nothing* in UEFI that precludes anyone else from having their keys directly in the firmware. They would need to work with multiple vendors, however. That's why it would have been a job for LF or Red Hat.
Incidentally, Microsoft Hyper-V 3 (launches with Server 2012R2) support secure boot and has UEFI firmware. And yes, you can register your own keys. If VMWare/Xen/KVM were to offer the same this will soon become a silly discussion as this would pertain only to the lowest level hypervisor layer on a host. I could certainly fathom VMWare working with server vendors to have *their* key pre-registered.
My issue is that I'm having a hard time seeing what SecureBoot adds that cannot be acheived in a better fashion (e.g. more comprehensive use of a TPM). SecureBoot doesn't ensure that your are booting is signed by someone you trust.
Yes it does. Especially on Windows, the OS is booted from signed cabinet files, i.e. the Microsoft bootloader will refuse to boot Windows unless the cabinet file (which include executables, libraries, core config files) is signed correctly.
It assures that one efi executable was signed by someone (who you may or may not 'trust'), but most would conceive of 'what you are booting' to be the universe of everything that happens prior to the system being usable, boot loader, kernel, configuration, third party executables, etc etc,
And if the bootloader and OS in turn takes on their part of that responsibility, you *do* have a trusted chain. Of course, it requires that the OS is booted from signed files that include executables as well as config. If the OS is set to require signatures (or hash matches) of 3rd party executables it can ensure integrity for itself. The chain merely ensures that each step can be confident that at the time where each step receives control of the system, integrity is ensured. Each step must ensure it's own integrity and only pass control to the next step if integrity can be validated.
Why do you assume that this is MAPP?
Because it fits the description and was confirmed by Microsofts Shaw as such (one of two programs) in the original Bloomberg article.
The question is this: Why would *you* think otherwise?
It's highly likely that NSA gets this information way before any one from the MAPP program does
Why? Citation needed.
it's also feasible to speculate that NSA could tell Microsoft to hold certain patches for a specific time period.
Do you make this up as you go? Is that tin foil hat uncomfortable? Pure FUD.
Yes, it is likely that the NSA have made requests like that. It is *highly* likely that Microsoft have *rejected* such requests, given that 1) they are not required under any law to grant such requests and 2) granting such requests could seriously damage trust in their products.
Now your going out on a limb. Stuxnet infected industrial machines (Siemens I believe) - not windows.
Wrong. Stuxnex infected Windows machines used to *control* industrial machines. It indeed infected Windows, but it only delivered it's payload when it had infected a Windows machine connected to specific Siemens equipment.
The "magical backdoor" is just an private key for signing windows modules as "trusted".
Minor correction: The _NSAKEY is a public key, the private part of which can be used to sign *cryptographic providers*. Windows will not accept just any cryptographic provider to be installed; it must be signed with one of the two built-in keys, one of which is the _NSAKEY. The key itself does not allow automatic installation, it is a way to avoid being *rejected* by Windows.
One can speculate why there is a special signing regime for crypto providers. However, there is a hint in the fact that the infamous key was found in a version of Windows that belonged to a time at which crypto algorithms bit bit sizes above 40 bits were considered class B weapons!
All windows machines accept any module as trusted if it is signed with that key.
Nope. Just cryptographic providers. And you must still explicitly *install* them. The they does not magically open up a backdoor to the internet and allow Microsoft or NSA to install "any module". And you don't need a crypto provider to compromise a system. A kernel mode driver will do.
Bruce Scheier or others in his field assume such keys to be under the protection of Microsoft and therefore "safe" (i.e. not a back door for loading malicious spy modules onto any windows machine - which any agency can do when they have access to the key/s).
Again, no. The key does not magically allow any agency to execute code on your or anyone else's Windows machines. The key can be used to avoid having a crypto provider rejected on installation.
if Microsoft giving NSA info on undisclosed vulnerabilities, they have in effect a magic backdoor in Windows.
Would you prefer that Microsoft tells foreign companies about vulnerabilities *without* informing the NSA about the same vulnerabilities?
The MAPP program is public and has been since it's introduction. As part of the program, Microsoft will release vulnerability information (and sometimes even PoC exploit code) to MAPP partners a few days in advance of releasing the patch for a vulnerability.
The reason is that a vulnerability patch is essentially the same as a disclosure. It is in the interest of both Microsoft, AV vendors and Microsofts' customers that AV vendors get a head start when creating scanning signatures that will catch exploit attempts.
Some of these AV vendors are foreign companies. Yes, some of them may be shells for or cooperate with e.g. a foreign intelligence service. Yes, even if they are only given a head start of a few days, there certainly is a risk that a foreign intelligence body could use the information to infiltrate US companies or government entities.
In that light, is it so terrible that the NSA get the information as well? You know, it could actually deter the foreign entity from actually attempting an exploit.
This is a fabricated scandal. Worse, it detracts from the *real* scandal, which is not what companies have been forced to hand over but rather the erosion of rights in the law.
and does it still send your password unencrypted?
So, when did you stop beating your wife?
The fact that almost no one knows about this menu is foolish... and a hint to what Microsoft has done wrong. I only found out about that menu because of tutorial software that ASUS ships on its Win8 notebooks.
No, it is proof that slashdot is full of ignorant and irrational Microsoft haters who take great pleasure in ranting about made-up problems they have never actually experienced themselves.
So what does DirectX 11.1 and .2 do that's so important that people will abandon Windows 7?
Per New or updated in Windows 8.1 Preview:
HLSL shader linking
Inbox HLSL compiler
GPU overlay support
DirectX tiled resources
Direct3D low-latency presentation API
DXGI Trim API and map default buffer
Frame buffer scaling
Multithreading with SurfaceImageSource
Interactive Microsoft DirectX composition of XAML visual elements
Direct2D batching with SurfaceImageSource
IMHO the big one is probably tiled resources. Think minecraft world virtually on the graphics card. From the applications perspective that it how it controls the graphics card. The app then also provides services for the graphics engine to request tiles with given scale at demand.
The correct one:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384649(v=vs.85).aspx
For a list of in-box (Windows' own internal VSS writers that ensure disk consistency) see here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb968827(v=vs.85).aspx
Oracle is an external VSS writer. Has supported VSS for many years.
mysqldump? But what you are doing, i.e backup of the database files directly, is a very dangerous form of backup. Restoring such when the database has been corrupted for whatever reason
Actually no, it is not dangerous provided that you use a backup agent or an operating system that supports this. Windows does, Linux and Unix do not.
On Windows the Volume Shadow Copy Service (VSS) will interact with registered processes to coordinate *when* they should ensure persistent consistency - which is reserved as a fraction of a second. It requires the processes to register as VSS writers - which database servers generally do (Oracle and SQL Server do - I do not know if MySQL does).
On Windows in a virtual environment this will even propagate through VM volumes, i.e. if you backup the host of the VMs (where some of the VMs could be running database servers), the host VSS service will ask the guest VSS service to ensure consistency right when the disk image file is being backed up. This means that you can backup the host Hyper-V server with all the disk images and rest assured that the VMs are consistent.
Huge boon for uptime.
Why would the score be higher for a server build? What use would a server have for a web browser? Surely they should be making more effort on the client version of the browser, where it might actually be used?
It is the same version, but running on the server it may disable some features because of security settings. Actually I'm surprised that WebGL is enabled on a server build, given that WebGL has the potential to inject and run code on your GPU.
However, there needs to be a server version for 1) those who install and maintain a server through it's own GUI and 2) servers used as "terminal servers". Yes, 1) is bad practice but it actually allows small shops to run their own server. Microsoft recommends installing servers as "server core" - i.e. with no GUI.
Does it not mean that the NSA can validly sign executables or libraries? It might not have a listening socket but the principles are the same.
Even if the private key belongs to the NSA (which is *extremely* unlikely - read Bruce Sneiers opinion) it would only mean that the NSA could sign *cryptographic providers*. It does not open any backdoor for the NSA to install software on your computer. The key is used to ensure that not just any cryptographic provider can be installed; it needs to be signed by Microsoft. You would still need to actually *install* the crypto provider. They signing would be used to ensure that it was not rejected by Windows.
If the NSA has a way to trick you into installing a crypto provider, you have bigger concerns than that. You do not need to install a crypto provider to pwn a system. Any system, any OS.
The key is from a time where cryptography was actually classified as weapons class B - and had export restrictions. At the time they could only ship with 40 bit (symmetric) keys. Too strong encryption would allow foreign entities to encrypt communication without the NSA being able to brute-force it. Those restrictions have since then been lifted as they were obviously stupid and only hurt US exports. Anyone who needed to encrypt messages with stronger keys would just use another product - even on Windows.
That said, the NSA is free to obtain an Authenticode certificate and sign executables just like anyone else.