Yeah, we sold an untold number of plastic boxes that don't work correctly if we ever stop responding to pings... Why would that ever be a problem? Companies never go bankrupt, deliberately kill old products, or 'change strategic direction'.
To the best of my knowledge, you don't have any alternative when it comes to getting the file; but stripping the DRM and reading it on something else does spare you the reporting that Adobe does of every move you make from one page to another, and keeping your copy of Digital Editions on a separate system(VM or isolated physical machine), will presumably keep it from scanning its merry way through your entire library...
Even if there were a 'clean' client, they'd still know who sent a request to their servers, and for what; but the ADE behavior goes well beyond that, and most of it will only work if the client is a traitor to the reader.
'Digital Editions' is Adobe's DRM-thing. I think that it can be applied to PDFs (along with ePub and maybe others); but nobody uses it just to render PDFs. Unfortunately, this also means that you now need DMCA-banned circumvention tools just to read a damn library book without Adobe looking over your shoulder...
I've seen alarm clocks that supposedly have blue LEDs; I will never buy one.
Given that blue light has the strongest disruptive effect on circadian rhythm (no idea whether it's just because blue photons are relatively energetic, or whether we evolved to respond strongly to lights that look rather like the sky during the day, I have no idea; but that's what the research says), you'll really start to need the alarm function after a few nights trying to sleep with one of those....
Applications specifically designed on the assumption that the user has a broadband connection are going to suck; but I certainly remember valuing (rather highly) having a computer powerful enough for web browsing even when I only had a 28.8 modem on a fairly noisy POTS line that often dragged it below its nominal best. People slightly older, or slightly more aggressive as early adopters, would likely say the same about even more feeble connections right back to the days of acoustic couplers.
This particular phone sounds like it has real issues implementing the 'smart' side of 'smartphone'; but you really don't need much bandwidth to make the additional power of a networked computer valuable.
I'm not so sure that Ubuntu would be pleasant on such a device; but, depending on what capabilities you can coax out of the microUSB port (and/or how many serial and GPIO pads/holes are reasonably accessible if you open the thing up), this device could actually be quite handy as a hacking platform...
The RAM is inferior to an rPi; but the CPU is nontrivially better(the A5 is the cheapest and weakest of the ARM v7 cores; but it's substantially more modern than the rPi's ARM11, and clocked faster); you get a small amount of onboard storage, with microSD expansion, plus wifi and dual-sim cellular...
Depending on exactly what GPIO/serial you can find inside without BGA-rework-heroism, and how cooperative the microUSB port is about running as an OTG host, you could have a pretty capable little project platform. I'd definitely like to have a look, if I can get my hands on one...
I've spent many a joyful hour gazing at the blue LED. My little blue pals.
It is a pity that their work inspired one of the most horrible trends in consumer electronics design... Seriously, the power light, on the front of the TV, where I'll be staring directly into it while trying to watch something?
Blue is pretty much necessary for LED illumination that doesn't look like some sort of emergency-power-failsafe-lighting scene; but damn is it ever overused...
I'm probably just getting old and bitter; but I remember wasting more hours than I should probably admit in public on the family PC, rocking an 83MHz 'Pentium Overdrive' with 16MB of RAM and an 800x600 CRT of deeply undistinguished performance. Something must have gone wrong if substantially more power is unequal to the task of painting an endurable UI on an even less demanding area of screen.
If the bored hacker with the killer app doesn't get you, you'll learn the hard way that violating the EULA and losing your license to operate a copy of the software really gets personal when that software is substituting for some organ system rathr than an external function...
It isn't USB specific(indeed, firewire and thunderbolt have rather juicier access to the system); but it is a bit of an issue because USB is the cheap, ubiquitous, externally exposed, bus for which all common OSes will happily support a fair variety of useful device types (USB HID, MSC, etc.) by default and without much user interaction.
The others tend to be less common, more expensive, and/or much less often externally exposed. None are innocent; but USB certainly looks like the most dangerous culprit.
That's not the issue: Since virtually all (x86) systems built later than 2010 are 64-bit, the expected case is 64 bit UEFI. Contemporary linux distributions don't even bat an eye at booting on a 64-bit system with 64-bit UEFI (well, there are a lot of ugly details under the surface, probably enough to keep several devs more or less permanently alcoholic; but the user doesn't need to see that).
However, there are a few edge cases that really haven't gotten enough attention and/or love to smooth them over: Apple has some older models with 32-bit EFI, and 64-bit CPUs, that are a bit weird, and there was a period where MS/Intel was using 32-bit Atom processors, with UEFI and no BIOS fallback, in order to hit aggressive price points for 'win-tablet' systems. These are a huge pain to boot to anything except the OS they were designed for; because distributions with good UEFI support almost always expect 64-bit CPUs, and 32-bit distros almost always expect BIOS booting.
There may be others; but the 'clover trail' based hardware that uses Z2760 or similar atom processors is what I'm talking about.
The laptops are based on the Celeron N2840, with 2GB of RAM. I can't seem to find much in the way of benchmarks; but I suspect that they are surprisingly adequate. What is a bit surprising is that the the N2840 has a quoted tray price of $107, so either Intel is cutting HP one hell of a deal, or I don't even want to know what HP cobbled the rest of the system together from...
Two different product lines: one is cheapy laptops(and since a touchscreen adds a nontrivial hit to the BOM, these don't come with them) and the other is inexpensive 7 and 8 inch tablets (which do have touchscreens, since they don't have keyboards or touchpads).
I would be interested, if I didn't have to run Windows on it.
You might want to be a bit careful, some of the ultra-cheap Windows devices are UEFI only; but 32 bit, which freaks most Linux installers out; but these are not Windows RT machines, so they will not be cryptographically locked out.
Time, and experimentation, will tell how good compatibility actually is; but it should be markedly easier than any Windows RT device, and honestly quite probably easier than doing a Linux port to a lot of common Android devices(yes, bodging a headless debian userland or something onto an Android system is easy; but getting X, using a mainline kernel, or not using bionic, less so...)
TFA doesn't provide enough detail to know for sure; but the problem may also be with expectations about what the system can do.
"Training" video snippets, regurgitated by various 'learning management systems' are something to be treated very carefully. Video tends to be slow and have poor information density as reference material(for, say, the arcana of some ghastly line-of-business software mess); but are also fairly shallow, and a bit condescending, as a substitute for a little hands-on guidance for your first time through a more complex activity. Does your company really deal in tasks so simple that a few youtube snippets can get you up to speed, or such churn that your colleagues can't spare some time to get to know the new guy?
(This is not to say that documentation isn't vital, it is, no human can be reasonably expected to remember all the arcane details; but 'reference material for people familiar with the task' and 'drool-proof intro videos' are extraordinarily different things.)
A wiki is a perfectly adequate CMS, if so configured, and if this is basically a vehicle for slinging video snippets at people the details of formatting are hardly going to be your biggest problem.
The more fundamental problem is that "Content management" and "Content" are fundamentally different things, and it's not a difference of degree. There is no CMS so brilliant, even in principle, that it will produce a single line of information for you. The best you can hope for is a system that auto-magics the production of indexes, bibliographies, other organizational stuff, and doesn't munge the formatting into unreadability.
You'd be better off with 'content' that is actually worthwhile tacked together with threadbare HTML hacked out in notepad than you would be with the finest of all possible CMSes and nothing to put in it...
If congress felt like passing a law regulating the matter, the interstate commerce clause would allow them to roll over the various state laws quite trivially(it's a very, very, elastic clause in general, and this would actually be pretty close to its intended use...); but 'Congress shall have the power' is not the same as 'Congress must exercise the power' to regulate interstate commerce.
Should a conflict arise, the states would be toast on this one; but it hasn't, yet.
Do you have a theory on what grounds Tesla could use to take the matter to court? Pure vexatious litigation isn't going to work against a target of this size, and it's far from obvious that anything is legally out of order with these assorted state bans.
Were the feds to take an interest, it'd be virtually certain that anything congress put out would supersede the state laws under the usual interstate commerce argument; but they haven't, so that isn't relevant for the moment. If they want to go to court, they'll need some argument about why the laws are legally unsound.
What is interesting, though, is how relatively subtle the changes are. Death and/or ghastly electrical burns? Unpleasant; but likely enough. It's the relatively modest changes to things like personality or perceived energy level that really take some unraveling.
In fairness, I was being a trifle hyperbolic(I figure that I've done my job when I manage a post that is insightful and funny enough that you don't select 'flamebait'; but nasty enough that you are tempted); but I do think that there is more than a bit of truth to it.
For the sake of fairness, some 'dashboards' do suck because they are all trees and no forest: a hell of a lot of blinky lights and numbers that look great on a display wall; but historical data are unavailable or buried and hard to turn into comparisions/health-over-time displays, and the arrangement as a whole is strongly biased in favor of spewing data as though data were actually equal to knowledge and understanding at the expense of being able to get a sense of what is actually going on.
However, that's not an argument in favor of reports, it's an argument against 'dashboards' that suck. A good dashboard should be malleable enough to provide a coherent historical overview, over the desired period, at a suitably chosen level of detail. A 'report'; but fully dynamic and drawing on the same basis as the 'dashboard'.
If the dashboard sucks, it needs fixing; but there does seem to be an aesthetic thing (the effect is strongest in movies/games about naval or spaceship combat: lots of minions, huddled over viewscreens, sometimes physically below the command dais in little peon pits, while the CO stands against a dramatic backdrop, touching none of the systems, operating at such a high level that occasional verbal interactions with his inferiors, and deliveries of summaries by the yoeman, tell him everything he needs to know. ). Yes, all moderately complex, or worse, systems are too big for any one person, and different people need different views; but if you think that you are so important that your view should differ in kind, rather than in configuration, you are mistaken.
TFA makes it sound like this is a relatively significant shift from in-house to contract work for NASA; but I've also read stuff over the years that gave the impression that a lot of 'in-house' NASA projects had, either as entire programs or as significant subcomponents, major involvement from various contractors, mostly the same ones that crop up in military/aerospace work.
Does this move represent an actual change in NASA's in-house capabilities, or is it more of a shift between "NASA Project: virtually all details brought to you by Lockeed-Martin" and "NASA just pays SpaceX to do the whole thing and present the results"?
I don't really want to get bogged down in a slugfest over whether it's a good thing or not(unless somebody has an interesting perspective on 'morale among directly-hired-by-NASA engineers' or some other actual information, not just a regurgitation of the usual talking points on in-house, contract, and COTS; but I would like to know what this shift represents: is NASA actually cutting back in favor of buying off-the-shelf, or is NASA just switching from 'contractors do most of the work, overall program is theoretically NASA' to 'Contract is for finished product, NASA is buying results, not parts.'
I'm amazed that Samsung was willing to work with him in the first place. To judge by their products, you can't do product development for Samsung unless your resume is utterly devoid of software that anybody would ever want to use.
It all comes down to movie psychology: A 'dashboard' is basically just a boring web based equivalent to the rows of screens and blinking lights and things that the jumpsuited minions hunch over, monitoring feverishly. A 'report' is the thing (piece of paper, datapad, etc. depending on era) that an obsequious yoeman hands to The Leader while he stands in a super-decisive Master and Commander pose in a suitably dramatic part of the set. The Leader then glances at the report and, thanks to the powers of decisive leadership, immediately gleans the relevant information and issues an order to rally his underlings.
'Dashboard' (while more useful) is basically a giant blinking signal that you are a peon, a cog in the machine. 'Report' is the executive summary with all the tedious detail drained out so that you can focus on being a big picture thinker and indispensable idea guy. It's like the difference between the giant bundle of keys that the janitor has (which can get you anywhere in the building; but show you to be a blue collar lackey) and the single RFID card that opens the suites on the top floor.
The big perk of single-sign-on (aside from keeping users from spewing crap passwords) is how nicely it centralizes the credential management. Create a new account? Do it in one place. Lock an account? One place. Change a password, one place. The fact that the user sees very few login screens aside from the initial one is a nice bonus; but not really the major perk for IT.
The assorted password managers in common use are Not aimed at 'faking' single-sign-on. They are aimed at helping a single user remember the credentials they create. If you scrounge, you can probably find an installer that can be automated and deployed; but actually provisioning the stored keys automatically? Automatically updating/reseting/etc. passwords across a zillion 3rd party services? You. Are. Screwed. Best case, roaming profiles, network home directories, or a little folder redirection will ensure that the user gets the same password store on any computer they log in to; but it will still be up to them not to make a total mess of it(and they will).
There is no hope. Honestly, your best bet is probably kidnapping family members of your vendors and threatening to release them in bits sized to fit a matchbox until your vendor gets off their ass and gets AD/OpenDirectory integration working.
Slashdot Mirror
This is Bank of America... "Abusive; but probably legal" would put their IT department above average for the company as a whole.
Yeah, we sold an untold number of plastic boxes that don't work correctly if we ever stop responding to pings... Why would that ever be a problem? Companies never go bankrupt, deliberately kill old products, or 'change strategic direction'.
To the best of my knowledge, you don't have any alternative when it comes to getting the file; but stripping the DRM and reading it on something else does spare you the reporting that Adobe does of every move you make from one page to another, and keeping your copy of Digital Editions on a separate system(VM or isolated physical machine), will presumably keep it from scanning its merry way through your entire library...
Even if there were a 'clean' client, they'd still know who sent a request to their servers, and for what; but the ADE behavior goes well beyond that, and most of it will only work if the client is a traitor to the reader.
'Digital Editions' is Adobe's DRM-thing. I think that it can be applied to PDFs (along with ePub and maybe others); but nobody uses it just to render PDFs. Unfortunately, this also means that you now need DMCA-banned circumvention tools just to read a damn library book without Adobe looking over your shoulder...
I've seen alarm clocks that supposedly have blue LEDs; I will never buy one.
Given that blue light has the strongest disruptive effect on circadian rhythm (no idea whether it's just because blue photons are relatively energetic, or whether we evolved to respond strongly to lights that look rather like the sky during the day, I have no idea; but that's what the research says), you'll really start to need the alarm function after a few nights trying to sleep with one of those....
Applications specifically designed on the assumption that the user has a broadband connection are going to suck; but I certainly remember valuing (rather highly) having a computer powerful enough for web browsing even when I only had a 28.8 modem on a fairly noisy POTS line that often dragged it below its nominal best. People slightly older, or slightly more aggressive as early adopters, would likely say the same about even more feeble connections right back to the days of acoustic couplers.
This particular phone sounds like it has real issues implementing the 'smart' side of 'smartphone'; but you really don't need much bandwidth to make the additional power of a networked computer valuable.
I'm not so sure that Ubuntu would be pleasant on such a device; but, depending on what capabilities you can coax out of the microUSB port (and/or how many serial and GPIO pads/holes are reasonably accessible if you open the thing up), this device could actually be quite handy as a hacking platform...
The RAM is inferior to an rPi; but the CPU is nontrivially better(the A5 is the cheapest and weakest of the ARM v7 cores; but it's substantially more modern than the rPi's ARM11, and clocked faster); you get a small amount of onboard storage, with microSD expansion, plus wifi and dual-sim cellular...
Depending on exactly what GPIO/serial you can find inside without BGA-rework-heroism, and how cooperative the microUSB port is about running as an OTG host, you could have a pretty capable little project platform. I'd definitely like to have a look, if I can get my hands on one...
I've spent many a joyful hour gazing at the blue LED. My little blue pals.
It is a pity that their work inspired one of the most horrible trends in consumer electronics design... Seriously, the power light, on the front of the TV, where I'll be staring directly into it while trying to watch something?
Blue is pretty much necessary for LED illumination that doesn't look like some sort of emergency-power-failsafe-lighting scene; but damn is it ever overused...
I'm probably just getting old and bitter; but I remember wasting more hours than I should probably admit in public on the family PC, rocking an 83MHz 'Pentium Overdrive' with 16MB of RAM and an 800x600 CRT of deeply undistinguished performance. Something must have gone wrong if substantially more power is unequal to the task of painting an endurable UI on an even less demanding area of screen.
If the bored hacker with the killer app doesn't get you, you'll learn the hard way that violating the EULA and losing your license to operate a copy of the software really gets personal when that software is substituting for some organ system rathr than an external function...
It isn't USB specific(indeed, firewire and thunderbolt have rather juicier access to the system); but it is a bit of an issue because USB is the cheap, ubiquitous, externally exposed, bus for which all common OSes will happily support a fair variety of useful device types (USB HID, MSC, etc.) by default and without much user interaction.
The others tend to be less common, more expensive, and/or much less often externally exposed. None are innocent; but USB certainly looks like the most dangerous culprit.
That's not the issue: Since virtually all (x86) systems built later than 2010 are 64-bit, the expected case is 64 bit UEFI. Contemporary linux distributions don't even bat an eye at booting on a 64-bit system with 64-bit UEFI (well, there are a lot of ugly details under the surface, probably enough to keep several devs more or less permanently alcoholic; but the user doesn't need to see that).
However, there are a few edge cases that really haven't gotten enough attention and/or love to smooth them over: Apple has some older models with 32-bit EFI, and 64-bit CPUs, that are a bit weird, and there was a period where MS/Intel was using 32-bit Atom processors, with UEFI and no BIOS fallback, in order to hit aggressive price points for 'win-tablet' systems. These are a huge pain to boot to anything except the OS they were designed for; because distributions with good UEFI support almost always expect 64-bit CPUs, and 32-bit distros almost always expect BIOS booting.
There may be others; but the 'clover trail' based hardware that uses Z2760 or similar atom processors is what I'm talking about.
The laptops are based on the Celeron N2840, with 2GB of RAM. I can't seem to find much in the way of benchmarks; but I suspect that they are surprisingly adequate. What is a bit surprising is that the the N2840 has a quoted tray price of $107, so either Intel is cutting HP one hell of a deal, or I don't even want to know what HP cobbled the rest of the system together from...
Two different product lines: one is cheapy laptops(and since a touchscreen adds a nontrivial hit to the BOM, these don't come with them) and the other is inexpensive 7 and 8 inch tablets (which do have touchscreens, since they don't have keyboards or touchpads).
I would be interested, if I didn't have to run Windows on it.
You might want to be a bit careful, some of the ultra-cheap Windows devices are UEFI only; but 32 bit, which freaks most Linux installers out; but these are not Windows RT machines, so they will not be cryptographically locked out.
Time, and experimentation, will tell how good compatibility actually is; but it should be markedly easier than any Windows RT device, and honestly quite probably easier than doing a Linux port to a lot of common Android devices(yes, bodging a headless debian userland or something onto an Android system is easy; but getting X, using a mainline kernel, or not using bionic, less so...)
TFA doesn't provide enough detail to know for sure; but the problem may also be with expectations about what the system can do.
"Training" video snippets, regurgitated by various 'learning management systems' are something to be treated very carefully. Video tends to be slow and have poor information density as reference material(for, say, the arcana of some ghastly line-of-business software mess); but are also fairly shallow, and a bit condescending, as a substitute for a little hands-on guidance for your first time through a more complex activity. Does your company really deal in tasks so simple that a few youtube snippets can get you up to speed, or such churn that your colleagues can't spare some time to get to know the new guy?
(This is not to say that documentation isn't vital, it is, no human can be reasonably expected to remember all the arcane details; but 'reference material for people familiar with the task' and 'drool-proof intro videos' are extraordinarily different things.)
A wiki is a perfectly adequate CMS, if so configured, and if this is basically a vehicle for slinging video snippets at people the details of formatting are hardly going to be your biggest problem.
The more fundamental problem is that "Content management" and "Content" are fundamentally different things, and it's not a difference of degree. There is no CMS so brilliant, even in principle, that it will produce a single line of information for you. The best you can hope for is a system that auto-magics the production of indexes, bibliographies, other organizational stuff, and doesn't munge the formatting into unreadability.
You'd be better off with 'content' that is actually worthwhile tacked together with threadbare HTML hacked out in notepad than you would be with the finest of all possible CMSes and nothing to put in it...
If congress felt like passing a law regulating the matter, the interstate commerce clause would allow them to roll over the various state laws quite trivially(it's a very, very, elastic clause in general, and this would actually be pretty close to its intended use...); but 'Congress shall have the power' is not the same as 'Congress must exercise the power' to regulate interstate commerce.
Should a conflict arise, the states would be toast on this one; but it hasn't, yet.
Do you have a theory on what grounds Tesla could use to take the matter to court? Pure vexatious litigation isn't going to work against a target of this size, and it's far from obvious that anything is legally out of order with these assorted state bans.
Were the feds to take an interest, it'd be virtually certain that anything congress put out would supersede the state laws under the usual interstate commerce argument; but they haven't, so that isn't relevant for the moment. If they want to go to court, they'll need some argument about why the laws are legally unsound.
What is interesting, though, is how relatively subtle the changes are. Death and/or ghastly electrical burns? Unpleasant; but likely enough. It's the relatively modest changes to things like personality or perceived energy level that really take some unraveling.
In fairness, I was being a trifle hyperbolic(I figure that I've done my job when I manage a post that is insightful and funny enough that you don't select 'flamebait'; but nasty enough that you are tempted); but I do think that there is more than a bit of truth to it.
For the sake of fairness, some 'dashboards' do suck because they are all trees and no forest: a hell of a lot of blinky lights and numbers that look great on a display wall; but historical data are unavailable or buried and hard to turn into comparisions/health-over-time displays, and the arrangement as a whole is strongly biased in favor of spewing data as though data were actually equal to knowledge and understanding at the expense of being able to get a sense of what is actually going on.
However, that's not an argument in favor of reports, it's an argument against 'dashboards' that suck. A good dashboard should be malleable enough to provide a coherent historical overview, over the desired period, at a suitably chosen level of detail. A 'report'; but fully dynamic and drawing on the same basis as the 'dashboard'.
If the dashboard sucks, it needs fixing; but there does seem to be an aesthetic thing (the effect is strongest in movies/games about naval or spaceship combat: lots of minions, huddled over viewscreens, sometimes physically below the command dais in little peon pits, while the CO stands against a dramatic backdrop, touching none of the systems, operating at such a high level that occasional verbal interactions with his inferiors, and deliveries of summaries by the yoeman, tell him everything he needs to know. ). Yes, all moderately complex, or worse, systems are too big for any one person, and different people need different views; but if you think that you are so important that your view should differ in kind, rather than in configuration, you are mistaken.
TFA makes it sound like this is a relatively significant shift from in-house to contract work for NASA; but I've also read stuff over the years that gave the impression that a lot of 'in-house' NASA projects had, either as entire programs or as significant subcomponents, major involvement from various contractors, mostly the same ones that crop up in military/aerospace work.
Does this move represent an actual change in NASA's in-house capabilities, or is it more of a shift between "NASA Project: virtually all details brought to you by Lockeed-Martin" and "NASA just pays SpaceX to do the whole thing and present the results"?
I don't really want to get bogged down in a slugfest over whether it's a good thing or not(unless somebody has an interesting perspective on 'morale among directly-hired-by-NASA engineers' or some other actual information, not just a regurgitation of the usual talking points on in-house, contract, and COTS; but I would like to know what this shift represents: is NASA actually cutting back in favor of buying off-the-shelf, or is NASA just switching from 'contractors do most of the work, overall program is theoretically NASA' to 'Contract is for finished product, NASA is buying results, not parts.'
I'm amazed that Samsung was willing to work with him in the first place. To judge by their products, you can't do product development for Samsung unless your resume is utterly devoid of software that anybody would ever want to use.
It all comes down to movie psychology: A 'dashboard' is basically just a boring web based equivalent to the rows of screens and blinking lights and things that the jumpsuited minions hunch over, monitoring feverishly. A 'report' is the thing (piece of paper, datapad, etc. depending on era) that an obsequious yoeman hands to The Leader while he stands in a super-decisive Master and Commander pose in a suitably dramatic part of the set. The Leader then glances at the report and, thanks to the powers of decisive leadership, immediately gleans the relevant information and issues an order to rally his underlings.
'Dashboard' (while more useful) is basically a giant blinking signal that you are a peon, a cog in the machine. 'Report' is the executive summary with all the tedious detail drained out so that you can focus on being a big picture thinker and indispensable idea guy. It's like the difference between the giant bundle of keys that the janitor has (which can get you anywhere in the building; but show you to be a blue collar lackey) and the single RFID card that opens the suites on the top floor.
The real hell is going to be administration:
The big perk of single-sign-on (aside from keeping users from spewing crap passwords) is how nicely it centralizes the credential management. Create a new account? Do it in one place. Lock an account? One place. Change a password, one place. The fact that the user sees very few login screens aside from the initial one is a nice bonus; but not really the major perk for IT.
The assorted password managers in common use are Not aimed at 'faking' single-sign-on. They are aimed at helping a single user remember the credentials they create. If you scrounge, you can probably find an installer that can be automated and deployed; but actually provisioning the stored keys automatically? Automatically updating/reseting/etc. passwords across a zillion 3rd party services? You. Are. Screwed. Best case, roaming profiles, network home directories, or a little folder redirection will ensure that the user gets the same password store on any computer they log in to; but it will still be up to them not to make a total mess of it(and they will).
There is no hope. Honestly, your best bet is probably kidnapping family members of your vendors and threatening to release them in bits sized to fit a matchbox until your vendor gets off their ass and gets AD/OpenDirectory integration working.