Hmm, that's a thought. (Incidentally -- no proxy, but we're likely to tie ourselves to IE real soon now, since the latest version of the MS handwriting recognition engine's features mostly aren't available through Mozilla, even with the ActiveX plugin).
Hmm. Thinking about it, we do still have one intrusive install-time dependency -- clients rely on DNS to find their server. To point the client at an internal address if it's being run from inside the company network or an external address otherwise, we need our customers to either slave the relevant (internal-addresses) zone off our DNS servers, or (if they don't run their own DNS) point their systems to use our app server as their DNS server (in which case it'll not only handle the relevant requests in-house, but also act as a caching DNS server, hopefully speeding up their network access a bit).
Of course, we can trivially get rid of this if users are willing to click on different icons to start the app based on whether they're at the office or not. I've also been meaning to ask some of the JavaScript types on the dev team if they can come up with a solution that doesn't negatively impact app startup time.
(Any suggestion you might offer -- or just feedback as to the [un]reasonableness of what we're currently asking and the abovementioned solutions -- would be appreciated).
My company makes electronic medical records software. A few months ago it came down the pipe that we were legally required to make a specific modification to the billing codes as of midnight on the last day of the month. The patch only got final approval by our QA department almost immediately before it had to be out in the field.
Without remote access to our fielded servers, we simply couldn't have pushed it out. We don't have enough people on the deployment team (support isn't trusted with administrative access on the fielded systems, though we give them access to monitoring tools) to log into all our fielded systems and run the update manually, nor would it be as consistant as remotely applying an automated patch that's been approved by our QA department.
Mind you, when I say "our fielded servers", I mean it. We own those systems (though our customers paid for them), we have sole administrative access to them, and they run no other software. Perhaps your situation's different.
That where the vendor's software is on a "black-box" machine that only they have administrative access to, and which runs no other software.
I'm (senior deployment engineer at) one of those vendors. Not only is our app fairly complex to administer, but every server that goes out contains a copy of the "secret sauce" -- not our application itself (which our bigger competitors could probably recreate in 9 months or less), but the data behind it (much more expensive and difficult to recreate). Consequently, our management is paranoid -- the servers are rigged to self-destruct (wipe the keys that allow them to decrypt the partition where all data is stored) in the event that any attempted tampering is detected, and can only be reenabled by the very small subset of our staff w/ access to the private keys.
Right now our app has components that run as 4 different users (to isolate breakins to the component where they occur), and includes a firewall and a VPN solution (both of which need root for obvious reasons).
Since it's our box that's running the app, and that same system does nothing else -- why restrict our access further? Absolutely, firewall us off from anything we don't need -- but restricting access to our box seems silly (and is something we'd consider only for a very large customer -- which is just as well, since the small folks we're selling to right now haven't had a problem).
In any event, I'm curious to hear how you'd respond.
I'm senior deployment engineer at one of those vendors (well, not one of your vendors, but similar kind of deal). One of the things I've put the most time into is building a (OpenVPN-based) administration infrastructure that'll work damn near anywhere. (If we need to, we can even tunnel over HTTP -- hasn't come to that yet, though).
Our integration components are likewise designed to be flexible and nonintrusive -- as much code as possible on our server, as little as possible on the system we're integrating with.
I'd like to think that when we start deploying to larger environments, these efforts will get noticed.
I'd think that having version-controlled symlinks in your source trees (which Arch supports but CVS doesn't) would be a more useful feature. Why would you want this?
When all you have for backup is a solaris machine with a tape drive
What's that have to do with the price of beans? Arch's archive format is actually *easier* to back up to tape because it's append-only (so you can have all changesets up to #500 on one archived tape and 501+ on another and never need to rewrite tho 1-500 tape because that history doesn't change).
When you need a web interface to update password...
What does that have to do with CVS? One can use PAM for authentication on the services Arch backends into (sftp, WebDAV, etc), so pretty much any kind of password store (and password change mechanism) one happens to want is possible.
I'd argue that setting up a darcs repository is easier than a CVS one -- you just initialize a working tree! (Even so, I'm not really a fan of darcs yet; my company works with very large trees, and so there's no way we could use it due to the memory and CPU time constraints; instead, we're switching to Arch).
On the other hand, in that situation the compiler isn't working for you. It isn't working against you, either, but a bug found for you is a bug you don't have to track down.
This is why I think Boo is so damn nifty. It's statically typed, but will infer types if possible (unless the user decides to use the optional explicit typing), and also allows duck typing to just resolve everything at runtime Python-style.
Mighty vague, that. What instances is CVS better in?
Compared to modern revision control systems, I don't think CVS is even in the running. It's SVN (in the non-distributed camp), and Arch, Darcs and Monotone in the distributed camp... with plenty of infighting between them.
Some people will learn a language because they want to know a language that has that specific set of features, regardless of what applications have already been written in that language.
It's a small group, but if you've the only game in town (in terms of OSS projects for them to work with)... well, that works out pretty well for you!
No, if Darcs has any major issues, it's the RAM and CPU time requirements, some of which the design makes inherently unresolvable.
It's poor taste to joke about something which addicts people, then takes their lives, hurting their families and friends.
Clue: Taste is a community concept. What the average individual in your community thinks is good/poor taste is good or poor taste, for purposes of interacting with the community as a whole.
You (that is, the folks who can't laugh about destructive, evil things) are part of a quite small minority. The rest of us can and do laugh about destructive, evil things -- what else is laughter there for, if not to help the pain go away?
But it is *not* on www.sun.com which is the main site that everyone uses to download java It's on an essentially hidden development site.
"Everyone"?!
java.sun.com is pretty damn near ubiquitously known to anyone who knows/cares about Java. it's not a "hidden development site", but rather the primary source for Java-related documentation and downloads from Sun.
Don't assume that "everyone" is as clueless as you are.
I hope that's true, but I don't see why you're so sure. There are many other good candidate reasons that Freenet is slow.
Most of the ones that come to mind could reasonably be considered to have fallen out of the system's design constraints.
From my perspective, blaming the design constraints first is a good rule of thumb in the same way that folks looking to optimize a tool's implementation should look at the algorithms it uses before looking into the details of how they're implemented. It may not always be where the problem's at, but as long as the folks doing the work are reasonably competant it's The Right Thing upwards of 80% of the time.
You *do* realize that Freenet is so slow on account of its design constraints wrt privacy and anonymity -- constraints that don't apply to this project -- right?
Well, yes, people sometimes need to work around other people's bugs.:)
I don't neceessarily think this acknowledgement clashes with absolving applications from blame for crashes, hangs and other such Bad Stuff the OS isn't supposed to allow them to cause.
No, I'm not; I'm simply apportioning blame. If the application triggers as OS bug, that's the OS's problem, not the application's.
(FYI, I'm the local system-level dude -- closest thing to an OS developer my company [whose product is a sealed-box OS-and-app solution] has on staff; this shapes my worldview wrt such issues).
Yes, you can steal the ballots -- but if you can't come up with a legitimate digital signature to barcode across each one (which you can't necessarily do w/o having an appropriate key -- and there are plenty of tricks that can be done to make that tough/impossible outside the geographic and temporal bounds of the election), having all the access you like to those paper ballots may not do you any good. Even simply removing some percentage of ballots cast in favor of the candidate one is opposed to can be detected, as it will result in a badly broken signature chain. Have each ballot include not only signature information but also a brief encoding (within the barcode) of the last 10 cast on the same machine, and you even permit error recovery in the case of lost ballots (while, again, using digital signatures to make this record tamper-evident). There are other techniques available to provide this record while making it impossible to determine any individual's vote, even knowing the order in which they used the machines, so long as the ballots in the box are mixed. (This requires a modification to traditional signature chaining, beyond the scope of this message).
It's been a while since I made a significant effort to keep up on modern crypto techniques -- but suffice to say that there's plenty that can be done to make any tampering with the paper record associated with an election thoroughly evident on audit.
Do you really think that the people who have the power to rig an electronic voting device can't steal/alter some paper in a ballot box? I don't.
It's harder. Ballot boxes are physical objects, and considerably more tamper-evident than electronic systems. What's even better is doing some fun with crypto (ie. chained signatures) on the physical pieces of paper in the box (using a printed barcode for the purpose). Using a combination of old-style (paper) and new-style (crypto) techniques, one could make election fraud very hard indeed to do undetectably.
Here's my idea: after you vote, you get a random ID and password associated with your vote. Later, you can log onto a website and verify that your vote is as you cast it, without divulging your identity.
...except that your boss (or that fellow who offered you $5 for your vote) insists on looking over your shoulder while you log onto this website.
Vote selling and related fraud has a very long history; part of the point of a good system is not to enable it.
I agree with you totally on this point. If they can write "You voted for liar #1" on screen but actually write something else to storage, why wouldn't they do the same thing on a paper receipt.
Because you drop the paper receipt in the flipping' ballot box, where it can be used in the event of a recount.
Is it really that hard of a concept?
Re:What day of the week is it?
on
Sun-isms Debunked
·
· Score: 2, Interesting
The parent claimed that Sun should have dropped a more mature, more cohesive, more scalable kernel and turned their attention to the Linux kernel. That's flat ludicrous from an investement standpoint.
Isn't it also what IBM did? Rumor is that they're making out rather well.
(Yes, I realize they haven't dropped AIX).
I sympathize, and I wouldn't try to get you to change. But I'd like to point out that this problem effectively makes Linux just as proprietary in a "lock in" sense as Solaris. You're locked in. If it does the job you need it to do, that's not necessarily a problem, but I hope the hard core zealots reading this recognize the spurious nature of arguing "but Linux is OPEN".
*shrug*. We can still switch vendors without having to totally rewrite everything (though I am, anyhow, since SuSE supports dm-crypt whereas RHEL only supported cryptoloop, which had security issues, forcing us to use loop-AES instead and deal with its performance corner cases)...
Aww, hell. Who am I kidding? If we were starting from scratch today, Solaris would be a very attractive option. When we were, it wasn't an option at all -- we were too broke to buy Sun's hardware. This was a startup where our CEO would work extra time on his day job (as an ER physician) to be able to afford to hire new people. We were broke, really damn broke, and avoiding upfront costs and getting something that would work right away was more important than getting something that work better but siphon off money that could be going to pay for our living expenses.
(Incidentally, my most recent experience w/ Solaris -- which is still pretty old -- wasn't exactly positive either. I was the one who got to fix apps when they didn't port cleanly. I still distinctly recall tracing through some unusually ugly app code to find a bug causd by Sun's ferror returning -1 rather than 0, as the man page and ANSI C spec'd, on an error-free stream. This didn't make me happy).
As for the true zealots -- well, they're zealots. They'll figure things out only when the crowd they think alike with does. That's not to say that there aren't a lot of folks out there who are using Linux for reasons not related to zealotry.
Re:Dear Angry Writer Who Doesn't Like Red Hat
on
Sun-isms Debunked
·
· Score: 3, Informative
Granted. Speaking as the fellow transitioning his company's deployment environment from RHEL3 to SLES9, though, RHEL has plenty of other things going against it.
I was very pleasently suprised on moving to SLES to find that it already had packages that formerly I'd been doing myself (Tomcat, JBoss); useful Oracle startup scripts; a considerably more featureful autoinstall systems (AutoYAST, as opposed to Kickstart); and a generally higher level of polish -- not to mention that Novell has local representatives who give us actual useful support. (Perhaps Red Hat would, too, if we paid them enough; I don't know. Novell has made aforementioned support available based just on the promise of future business -- the kind of customer-centric action that's left me very impressed).
All that said -- I've had bad experiences w/ ReiserFS myself, and your other specific objections are likewise valid. Even so, the author's arguably spot on in his preference among enterprise Linux distributions.
Re:What day of the week is it?
on
Sun-isms Debunked
·
· Score: 4, Interesting
Yes, modern Solaris has lots of nifty goodies that Linux doesn't. It has those things because Sun developed them for it. If Sun had "embraced Linux", as the parent suggests, it presumably would have developed them there instead. Not that I'm entirely clear on why it would have been in their best interests to do that -- but I don't see how/why your post really refutes, or even at all conflits with, its parent.
*shrug*. Personally, I'd probably be investigating Solaris 10 as a platform for deploying my company's products, but I'm already too busy moving from RHEL3 to SLES9 -- and a good chunk of our security-related infrastructure is somewhat OS-dependant and would need to be rewritten. Only so many hours in a day, etc.
If I'm not wrong, someone could do this with a legitimately-purchased copy, too, to avoid the delay involved in unpacking the GCF files.
I don't own a copy of HL2 yet (constrained in both time and money issues), but when I buy it I'll keep this in mind (presuming they haven't patched it away by then).
Slashdot Mirror
Hmm, that's a thought. (Incidentally -- no proxy, but we're likely to tie ourselves to IE real soon now, since the latest version of the MS handwriting recognition engine's features mostly aren't available through Mozilla, even with the ActiveX plugin).
Thankya!
Hmm. Thinking about it, we do still have one intrusive install-time dependency -- clients rely on DNS to find their server. To point the client at an internal address if it's being run from inside the company network or an external address otherwise, we need our customers to either slave the relevant (internal-addresses) zone off our DNS servers, or (if they don't run their own DNS) point their systems to use our app server as their DNS server (in which case it'll not only handle the relevant requests in-house, but also act as a caching DNS server, hopefully speeding up their network access a bit).
Of course, we can trivially get rid of this if users are willing to click on different icons to start the app based on whether they're at the office or not. I've also been meaning to ask some of the JavaScript types on the dev team if they can come up with a solution that doesn't negatively impact app startup time.
(Any suggestion you might offer -- or just feedback as to the [un]reasonableness of what we're currently asking and the abovementioned solutions -- would be appreciated).
My company makes electronic medical records software. A few months ago it came down the pipe that we were legally required to make a specific modification to the billing codes as of midnight on the last day of the month. The patch only got final approval by our QA department almost immediately before it had to be out in the field.
Without remote access to our fielded servers, we simply couldn't have pushed it out. We don't have enough people on the deployment team (support isn't trusted with administrative access on the fielded systems, though we give them access to monitoring tools) to log into all our fielded systems and run the update manually, nor would it be as consistant as remotely applying an automated patch that's been approved by our QA department.
Mind you, when I say "our fielded servers", I mean it. We own those systems (though our customers paid for them), we have sole administrative access to them, and they run no other software. Perhaps your situation's different.
There's a different kind of situation:
That where the vendor's software is on a "black-box" machine that only they have administrative access to, and which runs no other software.
I'm (senior deployment engineer at) one of those vendors. Not only is our app fairly complex to administer, but every server that goes out contains a copy of the "secret sauce" -- not our application itself (which our bigger competitors could probably recreate in 9 months or less), but the data behind it (much more expensive and difficult to recreate). Consequently, our management is paranoid -- the servers are rigged to self-destruct (wipe the keys that allow them to decrypt the partition where all data is stored) in the event that any attempted tampering is detected, and can only be reenabled by the very small subset of our staff w/ access to the private keys.
Right now our app has components that run as 4 different users (to isolate breakins to the component where they occur), and includes a firewall and a VPN solution (both of which need root for obvious reasons).
Since it's our box that's running the app, and that same system does nothing else -- why restrict our access further? Absolutely, firewall us off from anything we don't need -- but restricting access to our box seems silly (and is something we'd consider only for a very large customer -- which is just as well, since the small folks we're selling to right now haven't had a problem).
In any event, I'm curious to hear how you'd respond.
I'm senior deployment engineer at one of those vendors (well, not one of your vendors, but similar kind of deal). One of the things I've put the most time into is building a (OpenVPN-based) administration infrastructure that'll work damn near anywhere. (If we need to, we can even tunnel over HTTP -- hasn't come to that yet, though).
Our integration components are likewise designed to be flexible and nonintrusive -- as much code as possible on our server, as little as possible on the system we're integrating with.
I'd like to think that when we start deploying to larger environments, these efforts will get noticed.
That doesn't, but reasonable judges and juries should.
I'd argue that setting up a darcs repository is easier than a CVS one -- you just initialize a working tree! (Even so, I'm not really a fan of darcs yet; my company works with very large trees, and so there's no way we could use it due to the memory and CPU time constraints; instead, we're switching to Arch).
On the other hand, in that situation the compiler isn't working for you. It isn't working against you, either, but a bug found for you is a bug you don't have to track down.
This is why I think Boo is so damn nifty. It's statically typed, but will infer types if possible (unless the user decides to use the optional explicit typing), and also allows duck typing to just resolve everything at runtime Python-style.
Mighty vague, that. What instances is CVS better in?
Compared to modern revision control systems, I don't think CVS is even in the running. It's SVN (in the non-distributed camp), and Arch, Darcs and Monotone in the distributed camp... with plenty of infighting between them.
Some people will learn a language because they want to know a language that has that specific set of features, regardless of what applications have already been written in that language.
It's a small group, but if you've the only game in town (in terms of OSS projects for them to work with)... well, that works out pretty well for you!
No, if Darcs has any major issues, it's the RAM and CPU time requirements, some of which the design makes inherently unresolvable.
It's poor taste to joke about something which addicts people, then takes their lives, hurting their families and friends.
Clue: Taste is a community concept. What the average individual in your community thinks is good/poor taste is good or poor taste, for purposes of interacting with the community as a whole.
You (that is, the folks who can't laugh about destructive, evil things) are part of a quite small minority. The rest of us can and do laugh about destructive, evil things -- what else is laughter there for, if not to help the pain go away?
But it is *not* on www.sun.com which is the main site that everyone uses to download java It's on an essentially hidden development site.
"Everyone"?!
java.sun.com is pretty damn near ubiquitously known to anyone who knows/cares about Java. it's not a "hidden development site", but rather the primary source for Java-related documentation and downloads from Sun.
Don't assume that "everyone" is as clueless as you are.
I hope that's true, but I don't see why you're so sure. There are many other good candidate reasons that Freenet is slow.
Most of the ones that come to mind could reasonably be considered to have fallen out of the system's design constraints.
From my perspective, blaming the design constraints first is a good rule of thumb in the same way that folks looking to optimize a tool's implementation should look at the algorithms it uses before looking into the details of how they're implemented. It may not always be where the problem's at, but as long as the folks doing the work are reasonably competant it's The Right Thing upwards of 80% of the time.
Sweet! Maybe it will be as fast as Freenet!
You *do* realize that Freenet is so slow on account of its design constraints wrt privacy and anonymity -- constraints that don't apply to this project -- right?
Well, yes, people sometimes need to work around other people's bugs. :)
I don't neceessarily think this acknowledgement clashes with absolving applications from blame for crashes, hangs and other such Bad Stuff the OS isn't supposed to allow them to cause.
No, I'm not; I'm simply apportioning blame. If the application triggers as OS bug, that's the OS's problem, not the application's.
(FYI, I'm the local system-level dude -- closest thing to an OS developer my company [whose product is a sealed-box OS-and-app solution] has on staff; this shapes my worldview wrt such issues).
No, applications cannot lock up a system.
Applications can trigger a hardware, driver or OS problem that locks up the system -- but the app itself is not crashing your box.
Yes, you can steal the ballots -- but if you can't come up with a legitimate digital signature to barcode across each one (which you can't necessarily do w/o having an appropriate key -- and there are plenty of tricks that can be done to make that tough/impossible outside the geographic and temporal bounds of the election), having all the access you like to those paper ballots may not do you any good. Even simply removing some percentage of ballots cast in favor of the candidate one is opposed to can be detected, as it will result in a badly broken signature chain. Have each ballot include not only signature information but also a brief encoding (within the barcode) of the last 10 cast on the same machine, and you even permit error recovery in the case of lost ballots (while, again, using digital signatures to make this record tamper-evident). There are other techniques available to provide this record while making it impossible to determine any individual's vote, even knowing the order in which they used the machines, so long as the ballots in the box are mixed. (This requires a modification to traditional signature chaining, beyond the scope of this message).
It's been a while since I made a significant effort to keep up on modern crypto techniques -- but suffice to say that there's plenty that can be done to make any tampering with the paper record associated with an election thoroughly evident on audit.
Do you really think that the people who have the power to rig an electronic voting device can't steal/alter some paper in a ballot box? I don't.
It's harder. Ballot boxes are physical objects, and considerably more tamper-evident than electronic systems. What's even better is doing some fun with crypto (ie. chained signatures) on the physical pieces of paper in the box (using a printed barcode for the purpose). Using a combination of old-style (paper) and new-style (crypto) techniques, one could make election fraud very hard indeed to do undetectably.
Vote selling and related fraud has a very long history; part of the point of a good system is not to enable it.
I agree with you totally on this point. If they can write "You voted for liar #1" on screen but actually write something else to storage, why wouldn't they do the same thing on a paper receipt.
Because you drop the paper receipt in the flipping' ballot box, where it can be used in the event of a recount.
Is it really that hard of a concept?
The parent claimed that Sun should have dropped a more mature, more cohesive, more scalable kernel and turned their attention to the Linux kernel. That's flat ludicrous from an investement standpoint.
Isn't it also what IBM did? Rumor is that they're making out rather well.
(Yes, I realize they haven't dropped AIX).
I sympathize, and I wouldn't try to get you to change. But I'd like to point out that this problem effectively makes Linux just as proprietary in a "lock in" sense as Solaris. You're locked in. If it does the job you need it to do, that's not necessarily a problem, but I hope the hard core zealots reading this recognize the spurious nature of arguing "but Linux is OPEN".
*shrug*. We can still switch vendors without having to totally rewrite everything (though I am, anyhow, since SuSE supports dm-crypt whereas RHEL only supported cryptoloop, which had security issues, forcing us to use loop-AES instead and deal with its performance corner cases)...
Aww, hell. Who am I kidding? If we were starting from scratch today, Solaris would be a very attractive option. When we were, it wasn't an option at all -- we were too broke to buy Sun's hardware. This was a startup where our CEO would work extra time on his day job (as an ER physician) to be able to afford to hire new people. We were broke, really damn broke, and avoiding upfront costs and getting something that would work right away was more important than getting something that work better but siphon off money that could be going to pay for our living expenses.
(Incidentally, my most recent experience w/ Solaris -- which is still pretty old -- wasn't exactly positive either. I was the one who got to fix apps when they didn't port cleanly. I still distinctly recall tracing through some unusually ugly app code to find a bug causd by Sun's ferror returning -1 rather than 0, as the man page and ANSI C spec'd, on an error-free stream. This didn't make me happy).
As for the true zealots -- well, they're zealots. They'll figure things out only when the crowd they think alike with does. That's not to say that there aren't a lot of folks out there who are using Linux for reasons not related to zealotry.
Granted. Speaking as the fellow transitioning his company's deployment environment from RHEL3 to SLES9, though, RHEL has plenty of other things going against it.
I was very pleasently suprised on moving to SLES to find that it already had packages that formerly I'd been doing myself (Tomcat, JBoss); useful Oracle startup scripts; a considerably more featureful autoinstall systems (AutoYAST, as opposed to Kickstart); and a generally higher level of polish -- not to mention that Novell has local representatives who give us actual useful support. (Perhaps Red Hat would, too, if we paid them enough; I don't know. Novell has made aforementioned support available based just on the promise of future business -- the kind of customer-centric action that's left me very impressed).
All that said -- I've had bad experiences w/ ReiserFS myself, and your other specific objections are likewise valid. Even so, the author's arguably spot on in his preference among enterprise Linux distributions.
Yes, modern Solaris has lots of nifty goodies that Linux doesn't. It has those things because Sun developed them for it. If Sun had "embraced Linux", as the parent suggests, it presumably would have developed them there instead. Not that I'm entirely clear on why it would have been in their best interests to do that -- but I don't see how/why your post really refutes, or even at all conflits with, its parent.
*shrug*. Personally, I'd probably be investigating Solaris 10 as a platform for deploying my company's products, but I'm already too busy moving from RHEL3 to SLES9 -- and a good chunk of our security-related infrastructure is somewhat OS-dependant and would need to be rewritten. Only so many hours in a day, etc.
Hmm.
If I'm not wrong, someone could do this with a legitimately-purchased copy, too, to avoid the delay involved in unpacking the GCF files.
I don't own a copy of HL2 yet (constrained in both time and money issues), but when I buy it I'll keep this in mind (presuming they haven't patched it away by then).