Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment The asker is the answer to their own question (Score 1) 230

Kinda telling when the person asking about the death of flash doesn't realize they're the reason (I'm taking their claim about working on on the development of Flash at face value) and has to ask other people why. If they couldn't see the serious problems they created in the design or implementation (such problems are already enumerated in other posts), or didn't work to address them, then of course adoption will die off.

Comment Windows does track the source, but ignores it (Score 1) 236

Why don't they simply add another record ("source") to help make the driver comparison? A typical Microsoft solution I would say.

Windows already keeps track of the source when ranking drivers, it's just MSFT changed the default Window policy to ignore it (to address certain issues, some technical, some political) and apparently used this kludge to mitigate some of the tradeoffs. The blog description skipped over several steps on how Windows ranks drivers. The first and main criteria is on how a driver is signed (i.e., the source), and only after that does it potentially need to tie-break based on the blog's description of hardware IDs, dates, and file versions.

Lowest rank score wins, and an inbox driver (i.e., a driver included with Windows) is scored 0x0D000003, which is higher than a WHQL signature score of 0x0D000002 or 0x0D000001 (according to setupapi.h in the Windows SDK). However, in Windows 7 the default policy was changed to now treat all signers the same, which now effectively ignores the source. Apparently this date is used to still try to favor vendor drivers despite this change in policy.

Comment Re:What changes (Score 2) 85

You're talking theory, but the reality is that BIOS/UEFI updates aren't made very often (especially on consumer desktops). Hence OSes have their own microcode update mechanisms. MSFT rarely updates the Windows OS microcode (only for big issues) hence there can be a need for other ways to update like this driver.

Comment Re:Hardware or driver's issues? (Score 1) 289

Option #2 does exist--it's called a subvendor ID and is part of the baseline spec for PCI (ie it's not an optional extension). To prevent the generic driver Samsung would need to provide a driver that matches the PCI device and subvendor IDs and Windows will opt to use this driver over the generic OS driver since it's a closer match for the device's IDs. Windows doesn't have a good model for blacklisting device IDs for use with generic drivers--the cases I can think of is where MSFT was aware of broken hardware prior to an OS release (and either blacklists in the inf file or puts a workaround in the generic driver).

With USB&USB2 the drivers were shipped earlier (in terms of common availability of driver vs hardware) compared to USB3 so right or wrong the hardware was designed/implemented to work with the Windows OS driver. MSFT was much more tardy on USB3 so vendors had to create & ship their own drivers and later could play with MSFT's driver. Having said that MSFT's driver has been out for awhile now so I don't know what is Samsung's excuse if this is newish hardware (rather than a new discovery of a hack being used on older hardware).

Comment Re:Heh (Score 2) 134

On Windows using MSFT's compilers you'll never get the same binary twice. There's timestamps and GUIDs (the latter for uniquely associating a pdb with an executable file). Different file paths to the source tree can also cause differences. Sometimes it's straightforward to pick out & ignore the GUID, timestamp, and checksum bytes that changed, but often not.

Comment So much feedback and yet Microsoft ignores it all (Score 1, Insightful) 112

The amount of feedback isn't surprising, but I would be surprised if anyone in the Redmond bubble ever made any changes (even slight) in response to any of that feedback. By the time they have a public release they're too far along in their big-company release process to accomodate changes.

Submission + - Several new OpenSSL vulnerabilities announced

revmoo writes: According to this security advisory, several new vulnerabilities have been discovered in OpenSSL across several versions. Hopefully admins have caught up on their sleep after the Heartbleed vulnerability.

Comment Re:Only "discovered" someone's discover, nothing m (Score 1) 357

I certainly agree that a redesign isn't a smoking gun. This does have the potential to also work against the public's best interest. E.g., an engineer could propose a change to improve reliability of a part or that might potentially increase safety. Management then refuses the change because someone else might later "discover" the change and use it in litigation against the company as "proof" that it was a known defect.

Slashdot Top Deals

Elliptic paraboloids for sale.

Working...