Speaking as someone who has actually used SF’s assessor software in SF city hall (as a public citizen to lookup property records) I think they’ve making the common mistake of not realizing that introducing a mouse always hinders productivity (people are always faster keeping their hands on a keyboard and navigating via menu).
The software is 80x25 and does look like a DOS app though behaves more like a unix or mainframe terminal app. The multi-user aspect might contribute to the replacement cost estimate but there’s gotta be lots of other software available that was already written for other counties.
The “prone to mistakes” is a hiring issue (gov’t at its best), not a software issue. They’ve got a lot of errors in how docs are recorded and indexed that reveal sloppy and lazy work.
I often tell people that Google Docs is the feature set of 1990s MSFT Office at 1980s speed (eg Microsoft Multiplan on a TI-99/4A). I suppose Google is trying to mask how horrible their stuff is by raising a generation of people who’ve never used anything else and don’t know how much better things can be (ie, ignorance is bliss).
More like who only gets paid 5 figures in pounds, euros, or US/OZ/NZ dollars? The results talk about 35k vs 38k when the starting base salary for a new grad in Silicon Valley is at least 6 figures. Apparently location is roughly an order of magnitude more important than this survey's concern about a degree.
It's always been the case that the voicemail systems for cell phones have a generic number that can be used to access the system itself (at which point the system prompts for which phone number you want to use for leaving or accessing a message). Generally there's a known mapping for region or phone prefix to VM number (e.g., an example or two) though I think at least AT&T uses one system and number for all iphones. The only thing that's new is telemarketers realizing they might be able to workaround the restrictions by using this route.
I'm jazzed about having something compatible with newer versions of windows.
I'm bummed that they completely broke it running on XP. I upgraded my existing paid product and it failed to start. Ditto with a clean install. I reinstalled from CD and patched to 1.61 and things are working again.
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.
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.
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.
Earlier USBs involved cpu-based polling, but xhci is based on the host controller polling an then interrupting the CPU. Section 5.2.8 of the xchi spec defines the MSI and MSI-x capabilities, which would be missing and irrelevant if your assertion about no hardware interrupts was correct.
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).
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.
AKA "silent mode" installs that people who actually know anything about Windows have been using for automated installs for almost as long as Linux has existed. MSFT was already providing apps/CLIs like dism for their own packages.
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.
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.
All he did was notice a change in parts, ie, the outcome of an Delphi engineer's actual discovery. Not at all news or noteworthy. It would have been if Delphi hadn't already fixed it and he did the initial discovery.
MSFT must agree Win 8 is shit, which is why its support is ending in just 2 years in January 2016. The preinstall aspect must explain why its market share grew despite the pending doom.
This is being handled differently than Vista SP1, which was really a disguised upgrade of Vista to Server 2008's codebase but it didn't involve an actual heavyweight OS upgrade & software reinstall (which seems to be the case for going from Win 8 to 8.1).
There's the proverb about not attributing to maliciousness that which can be explained by stupidity.
VMware (also an EMC subsidiary) used an RSA implementation for their SSO product. It had a ton of problems and bugs, and each new patch release introduced more bugs. Applying pressure to RSA via EMC didn't help, so VMware ripped out the RSA implementation with a band new in-house implementation.
There's a big difference between Windows where problems are a corner case, vs. Linux where success is a corner case. But the point still remains that I've used sleep and hibernate on most of my Windows machines without really fearing problems or data loss (I'll still save any progress before initiating it, though thanks to Office 97 I'm in the habit of saving regularly regardless), but I can't think of even bothering to try such a thing on Linux (nor can even of the people I know who love Linux enough to actually enjoy updating to a new distro every few months/years). I probably won't even think of trying to use sleep or hibernate on a Linux box until I see that the Linux kernel has developed drivers models that have some hint of being designed with power management in mind. Heck even the PCI driver model in Linux doesn't fit the spec well. Most Linux drivers I've had to deal with need to mess with the device's PCI configuration space themselves, whereas on Windows that's pretty rare because it's usually handled by the core kernel (which was the intent of the PCI spec based on how it's written).
Power Management has worked well on Windows for 15+ years. I'm still waiting for Linux's first year, so problem on Linux are with the kernel and/or the drivers.
As the posts there point out that only works if you're still in range of the old network. It's a pain to have to remember to forget a network each time I check out of a hotel, nor do I want to have to reset all settings and reteach the phone about the networks I do want it to use.
I've wanted the ability to tell my iPhone to forget old networks so it doesn't waste time and power sending probe frames trying to provoke any hidden access points/SSIDs to advertise themselves. The security concern raised by this article is yet another.
Slashdot Mirror
Speaking as someone who has actually used SF’s assessor software in SF city hall (as a public citizen to lookup property records) I think they’ve making the common mistake of not realizing that introducing a mouse always hinders productivity (people are always faster keeping their hands on a keyboard and navigating via menu).
The software is 80x25 and does look like a DOS app though behaves more like a unix or mainframe terminal app. The multi-user aspect might contribute to the replacement cost estimate but there’s gotta be lots of other software available that was already written for other counties.
The “prone to mistakes” is a hiring issue (gov’t at its best), not a software issue. They’ve got a lot of errors in how docs are recorded and indexed that reveal sloppy and lazy work.
I often tell people that Google Docs is the feature set of 1990s MSFT Office at 1980s speed (eg Microsoft Multiplan on a TI-99/4A). I suppose Google is trying to mask how horrible their stuff is by raising a generation of people who’ve never used anything else and don’t know how much better things can be (ie, ignorance is bliss).
who gets paid in pounds lol
More like who only gets paid 5 figures in pounds, euros, or US/OZ/NZ dollars? The results talk about 35k vs 38k when the starting base salary for a new grad in Silicon Valley is at least 6 figures. Apparently location is roughly an order of magnitude more important than this survey's concern about a degree.
It's always been the case that the voicemail systems for cell phones have a generic number that can be used to access the system itself (at which point the system prompts for which phone number you want to use for leaving or accessing a message). Generally there's a known mapping for region or phone prefix to VM number (e.g., an example or two) though I think at least AT&T uses one system and number for all iphones. The only thing that's new is telemarketers realizing they might be able to workaround the restrictions by using this route.
I'm jazzed about having something compatible with newer versions of windows.
I'm bummed that they completely broke it running on XP. I upgraded my existing paid product and it failed to start. Ditto with a clean install. I reinstalled from CD and patched to 1.61 and things are working again.
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.
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.
I didn't think there was a single 32-bit retina iOS device anyway.
The iPhone 5 is a 32-bit retina device.
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.
Earlier USBs involved cpu-based polling, but xhci is based on the host controller polling an then interrupting the CPU. Section 5.2.8 of the xchi spec defines the MSI and MSI-x capabilities, which would be missing and irrelevant if your assertion about no hardware interrupts was correct.
USB 3 (AKA xhci) has interrupts. It was designed to reduce power consumption and reduce overhead to virtualize in a VM.
This parent article seems to be pretty poor when it asked what USB has replaced and most of the replies are about what USB hasn't yet replaced.
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).
Regardless this seems like a pretty crappy study. There's many other phrases like kludge or XXX to have considered.
It's hard to make extensible for newly installed products, and nowadays lots of file formats are a renamed zip file that contains other files.
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.
AKA "silent mode" installs that people who actually know anything about Windows have been using for automated installs for almost as long as Linux has existed. MSFT was already providing apps/CLIs like dism for their own packages.
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.
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.
All he did was notice a change in parts, ie, the outcome of an Delphi engineer's actual discovery. Not at all news or noteworthy. It would have been if Delphi hadn't already fixed it and he did the initial discovery.
MSFT must agree Win 8 is shit, which is why its support is ending in just 2 years in January 2016. The preinstall aspect must explain why its market share grew despite the pending doom.
This is being handled differently than Vista SP1, which was really a disguised upgrade of Vista to Server 2008's codebase but it didn't involve an actual heavyweight OS upgrade & software reinstall (which seems to be the case for going from Win 8 to 8.1).
There's the proverb about not attributing to maliciousness that which can be explained by stupidity.
VMware (also an EMC subsidiary) used an RSA implementation for their SSO product. It had a ton of problems and bugs, and each new patch release introduced more bugs. Applying pressure to RSA via EMC didn't help, so VMware ripped out the RSA implementation with a band new in-house implementation.
There's a big difference between Windows where problems are a corner case, vs. Linux where success is a corner case. But the point still remains that I've used sleep and hibernate on most of my Windows machines without really fearing problems or data loss (I'll still save any progress before initiating it, though thanks to Office 97 I'm in the habit of saving regularly regardless), but I can't think of even bothering to try such a thing on Linux (nor can even of the people I know who love Linux enough to actually enjoy updating to a new distro every few months/years). I probably won't even think of trying to use sleep or hibernate on a Linux box until I see that the Linux kernel has developed drivers models that have some hint of being designed with power management in mind. Heck even the PCI driver model in Linux doesn't fit the spec well. Most Linux drivers I've had to deal with need to mess with the device's PCI configuration space themselves, whereas on Windows that's pretty rare because it's usually handled by the core kernel (which was the intent of the PCI spec based on how it's written).
Power Management has worked well on Windows for 15+ years. I'm still waiting for Linux's first year, so problem on Linux are with the kernel and/or the drivers.
As the posts there point out that only works if you're still in range of the old network. It's a pain to have to remember to forget a network each time I check out of a hotel, nor do I want to have to reset all settings and reteach the phone about the networks I do want it to use.
I've wanted the ability to tell my iPhone to forget old networks so it doesn't waste time and power sending probe frames trying to provoke any hidden access points/SSIDs to advertise themselves. The security concern raised by this article is yet another.