Nobody says you shouldn't share them, but you're going to have to also understand that other people won't necessarily want them and have their own to share with you as well. That's all fine of course if everyone is civil about it. Things rarely remain civil in these situations however. I'd note that RMS isn't exactly known for being civil either...
My point is there's nothing wrong with a tool that lets you extend your search to google or wherever. It isn't inherently bad. YOU may not like it, you are certainly entirely welcome to your opinion, its fine. However it becomes nonsensical when you start talking about something like Ubuntu being evil for providing a tool that YOU PERSONALLY don't approve of. Just don't use it. Go ahead and tell Mark Shuttleworth you aren't using it. Sure, tell him why. Just don't expect to be taken seriously when you call Ubuntu evil...
is how does Canonical present this choice. If its hard coded and not documented, that's one extreme. If it is an option you openly select with a checkbox every time that's probably the other extreme. RMS IMHO is getting all hot and bothered about the wrong things. If we CAN'T have options to interact with external services then we have NO choice, that's not freedom. He's got a fixed view of things like that, and it is just not appropriate. Its also cultural. While we can say people should be entitled to a private and a public life you're not going to find very much agreement across cultures of what that means.
Oh, there are decent newish keyboards, but honestly the feel is IMHO inferior to the good old Model M. Guess I grew up on actual Selectric typewriters and such, lol. Nothing like learning to type on an IBM cardpunch machine CA 1970...
Mine is of the very oldest vintage too. The local recycle place put out a BOX of them a few years ago. I snapped up the whole box for like $10. Still got 3 of these beasties and they're the best peripheral ever made if you ask me. Takes a bit of a stack of adapters to get to USB with the thing, but I got there...
And for you who haven't experienced the Zen of it all the lack of the 'windows' key and such crud is a blessing;) I can do 120 WPM with this baby.
Well, I gotta say, there is less diversity out there. OTOH you really had to be doing some niche stuff even in the old days to be writing code for Novix chips, transputers, Swann systems, and such.
Crap, it may be a holy grail for x86 but only because x86 virtualization sucks so bad. Go run your stuff on a 360/Z/P series architecture and you've been able to do this stuff since the 1960s because you have 100% airtight virtualization.
Of course ANY such setup, regardless of hardware, is only as good as the hypervisor. It is still not really clear what is actually gained. Truthfully no degree of isolation is bullet proof because whatever encloses it can look at it and there will ALWAYS be some set of inputs to that wrapping layer that will subvert it.
In any case, I'm not up on L4. In my OS design days if you wanted that level of performance you simply ran in a single flat address space with relocatable code (OS9/68k for example) and then ran your security code in a separate processor.
Really depends on the CPU architecture. You can't generalize a lot about that kind of thing. TLB is invalidated in x86. I'm a little sketchy on the ARM situation, but 68k and PPC architectures have a rather different setup than x86.
Context switches between threads generally aren't as expensive, yes, because the whole point with threads is shared address space, which is primarily for this very reason. However, there are still issues with locality, instruction scheduling, etc. There ARE also often changes in addressing if for no other reason than supervisor needs different tables to specify its different permissions. Again, there are many different impacts on performance. It is really not material if this is because of a change in mode or in addressing, these are exactly the switches that microkernels amplify.
Yeah, this is true. I think if you were to start at zero and design a CPU architecture with a microkernel specifically in mind some clever things would come out of that and help even the playing field. Of course the question is still whether it is worth it at all. Until microkernels show some sort of qualitative superiority there's just no real incentive.
Uhhhhhhh, wait a minute. I was an avid Amiga programmer back in the day. AmigaOS wasn't in any particular sense a microkernel. Such distinctions in fact would be largely meaningless because AmigoOS was written to run on the MC68k processor, a chip which had no MMU nor any facilities for address translation at all (though in theory you could implement storage backed virtual memory it wasn't terribly practical). Every Amiga program was address independent, it could load and run at any address, and all software on the machine, applications and OS necessarily shared a single address space.
There was a considerable amount of message passing between AmigaOS components, but no more than you would expect to see in a modern display manager (IE like X distributes UI events as messages via the X protocol). At a low level you simply made calls into the Amiga system ROM, where pretty much all the kernel functionality was located, and/or tweaked around with hardware directly depending on how friendly your program cared to be WRT to letting other stuff run at the same time.
Most games for instance simply took over the machine and tossed the whole intuition layer out, called ROM directly, and often seized direct control of things like the Copper (advanced DMA controller basically, this drove most of the cool stuff Amiga could do). Such a program would not work at all with other software and you would only run it by itself from its own boot disk usually.
A lot of software would 'play nice' with the rest of the system and only merge its stuff into the copper list via the APIs and keep to whatever memory it was allocated. In that case you had a standard desktop type program, which could either manage an entire screen or live inside a desktop window. A lot of games ran like this, grabbing their own screen but allowing you to run other applications at the same time, return to the OS, etc. Generally productivity apps or utilities might run in actual desktop windows, in which case you would use the intuition GUI toolkit libraries.
ALL context switches are expensive. The primary effect of a context switch is that each context has its own memory address layout. When you switch from one to another your TLB (translation lookaside buffer) is invalidated. This creates a LOT of extra work for the CPU as it cannot rely on cached data (addresses are different, the same data may not be in the same location in a new context) and consequent cache invalidation, etc. It really doesn't matter if it is 'user' or 'kernel' level context, the mechanics are all the same.
All interrupts in processors are handled in a single context, the 'ring 0' or 'kernel state'. Device drivers (actual drivers that is) handle interrupts, that's their PURPOSE. When the user types a keystroke the keyboard controller generates an interrupt to hardware which FORCES a CPU context switch to kernel state and the context established for handling interrupts (the exact details depend on the CPU and possibly other parts of the specific architecture, in some systems there is just a general interrupt handling context and software does a bunch of the work, in others the hardware will set up the context and vector directly to the handler).
So, just HAVING an interrupt means you've had one context switch. In a monolithic kernel that could be the only one, the interrupt is handled and normal processing resumes with a switch back to the previous context or something similar. In a microkernel the initial dispatching mechanism has to determine what user space context will handle things and do ANOTHER context switch into that user state, doubling the number of switches required. Not only that but in many cases something like I/O will also require access to other services or drivers. For instance a USB bus will have a USB driver, but layered on top of that are HID drivers, disk drivers, etc, sometimes 2-3 levels deep (IE a USB storage subsystem will emulate SCSI, so there is an abstract SCSI driver on top of the USB driver and then logical disk storage subsystems on top of them). In a microkernel it is QUITE likely that as data and commands move up and down through these layers each one will force a context switch, and they may well also force some data to be moved from one address space to another, etc.
Microkernels will always be a tempting concept, they have a certain architectural level of elegance. OTOH in practical terms they're simply inefficient, and most of the benefits remain largely theoretical. While it is true that dependencies and couplings COULD be reduced and security and stability COULD improve, the added complexity generally results in less reliability and less provable security. Interactions between the various subsystems remain, they just become harder to trace. So far at least monolithic kernels have proven to be more practical in most applications. Some people of course maintain that the structure of OSes running on systems with large numbers of (homogeneous or heterogeneous) will more closely resemble microkernels than standard monolithic ones. Of course work on this sort of software is still in its infancy, so it is hard to say if this may turn out to be true or not.
What's your excuse for the US, which when you count in state liabilities, etc (which you are counting with the EU countries) it is FAR FAR FAR worse off than even Greece.
Look up the term "bucket shop" for instance. It is one thing to say be a registered CFTC regulate exchange and regulated FCMs (Futures Commission Merchant), IBs, etc. In this case if I buy a gold contract THERE IS GOLD behind that contract, there is sufficient liquidity to guarantee that the trade will settle, the DTC or some other facility will insure that trades ARE settled, order flow is monitored for front running, etc etc etc. The main point there is however that the liquidity exists and that the investor is actually participating in the market.
For instance a bucket shop would simply let you 'buy' gold for instance, but in reality they would just take your money. If gold goes down and you exit the market they get to keep some of that money. If OTOH it goes up and you take your profit they can't cover it (except by raiding someone else's account). InTrade isn't participating in markets, it is just letting you 'bet', which is not the same thing. You're playing the market effectively AGAINST them.
Interestingly the only market where this effectively DOES work is spot FX. Because there is nothing but cash in FX in different currencies all FX trading IS in effect betting. Even then the US now pretty much forbids retail FX trading, the business has moved overseas.
Banks, and any depository institution falls into this category, have quite sophisticated KYC (Know Your Customer) policies in place, which are mandated by both national and international law. You would simply never be able to open an account with InTrade, period. If you think using a VPN is going to fool them, they don't even look at that kind of thing. You're going to provide them with documentation about where the money came from and who you are when you sign up. No doubt there ARE ways to skirt these procedures for small amounts of money or people who will (illegally) act as a proxy (say your cousin who happens to live in London or something) the vast majority of US citizens will just get nowhere when they try to do business with InTrade.
Nah, you have to have KYC type AML procedures in pretty much every country in order to operate this sort of business. What ACTUALLY happens is a company like InTrade says to itself "if we don't apply proper KYC and do business with US citizens then the US will do nasty things like seize our assets", and that's pretty much the end of it. Even if InTrade has no assets in the US or in US controlled banks there are actually agreements between all western countries about this sort of thing.
Oh, no doubt about it. At least in our case the thing is you probably have to start with planning at a higher level. Our customer would start by thinking about business needs, features, performance, reliability of the whole platform, and various integration needs and desires they would have. Then we would engineer them a deployment plan in conjunction with their IT people. It will be decided where the various services are deployed, are they using Kerberos, internal authz, AD, some other LDAP service, etc. for authentication. Is there external client network access required? Is it happening via a VPN, SSL, into a DMZ? If so then is there a separate server handling that, is it clustered, how is failover being handled? Do the core servers reside on the same network or on the other side of the DMZ? What about other incoming and outgoing data streams, how is high reliability being handled there? Do we have to assist in establishing SLAs? Are there extra pieces the customer needs to monitor those? There's just endless amounts of details with this stuff. It gets pretty crazy. Basically a lot of the reason we exist is to deal with all this kind of stuff, guide clients, and provide them with the information they need to make decisions and/or handle things on their own. We do have manuals, and you can definitely install the software based on the manual, but chances are you won't have a good grasp of the best ways to use it and achieve your business goals without help. I don't know how to capture all of that in any written form. I've got a large wiki, but even then you can only convey so much. A lot of it is just familiarity with the problems and knowing what kind of stuff will or won't likely work.
I think what you'd find is that each install is unique enough that the effort needed to set up an install script which would have to be gone over with a fine toothed comb and tested several times just to do one or two customers wouldn't be cost effective. We've looked into these things in the past, trust me.
In fact you're probably wrong about perceptions. Everyone enjoys convenience and simplicity. Automatic installer scripts would generally convey a polished appearance, BUT our customers are our customers because of the significant savings and ability to integrate into their own business process and flexibility that our product gives them vs what they have from other vendors. Of course they'd love to pay less, but they know the deal they're getting from us is great for them and that we don't charge stupid amounts of money for nothing. All I can say is we are doing something right because business grows every year.
Exactly. There are just such a HUGE number of different possible things that can go into an individual setup. There are in our main 2 pieces of product each a rather extensive and tricky XML file that you're almost certain to have to do some significant surgery on. It is POSSIBLE you can set up a 'vanilla' setup for demo purposes basically, but you're sure to have to edit this beast real soon anyway.
There are other aspects too. While I say our system is a 'piece of software' it is really a number of services which can be distributed in different ways between however many machines someone needs for their purposes, and there are several ways you could do that. Depending on exactly how you actually set things up there could be various quirky setup and configuration issues. In most cases the specific setup is one that hasn't been entirely tested before or even entirely anticipated. Often you're dealing with the person that designed some part of things to know exactly how (or even if) something can be done. This is mainly because this sort of software is EARs deploying onto J2EE servers, databases (there are 4 separate schemas that we use for various things, they might well not even be on the same servers). It is just complex and ugly.
I think people get the misimpression from what I said that we aren't concerned with making things easy and smooth. That wouldn't be true. Ease of use is always a concern for any decent ISV. It is just that some issues aren't reducible to a few choices in an install wizard, and there are just factors that aren't sensible to deal with at that level. In fact there are a lot of automation scripts of various types that we use. All database updates for instance are done via a structured set of script modules that we wrote years ago. That can reduce a really complex process to a couple shell commands. Other bits of software DO have installers.
Yet another incipient genius who probably hasn't had the slightest experience on the ISV side of this equation with the convenient one-size-fits-all answer to end all answers. Thanks, that was amazingly edifying!
Frankly, you have NO FUCKING CLUE what you're talking about. I would presume you really have no familiarity with actual commercial line-of-business enterprise class software. Any enterprise which is not run by morons and is large enough to qualify as an 'enterprise' has an extensive IT infrastructure which is highly integrated and designed around an enterprise information systems architecture, involves capacity, availability, security, and usability analysis and planning etc. When you 'deploy' software into these environments, and I'm talking about large banks, Fortune 500's, large international corps mainly there's no such thing as "drop the installer on a hard drive and run it". You're dealing with integrated management systems, enterprise-wide credentials and role management, complex licensing situations, other corporate IT policy issues, etc etc etc. The idea that MY software, which handles transactions from generally 1000's of clients and integrates with easily on average 4-5 other complex software stacks is 'lacking an installer' because you don't install it clicky--click is hilarious.
You can think what you want, but at least in my world 'enterprise software' means something very different from what some people seem to be using it for. This is not like in your typical small business environment where you slap up a copy of Apache and install Trac on it and call it a day (and even there I'll note there's no single installer that can handle setting that up for you).
Because most Enterprise software (and I manage a product line which is definitely in this category) isn't something so simple that you can install it with RPM or Installshield (or whatever the heck MS calls it now). There are multiple interacting services, very specific dependencies for things that are often not packaged at all for the target platform and usually cannot be distributed, etc. Complex databases, usually on other machines, have to be set up, XML files edited, etc to even create a basic working environment for our software. Now, MOST things might not be quite this complicated, but I suspect most software that you have to install largely by hand has many of these kinds of issues. Most of this stuff has to integrate fairly deeply with the client's IT infrastructure and setting up the basic applications is only a small part of it.
In our case we have some installers for some specific tools, but the main product? No, it wouldn't materially assist in setup and would just be yet another task to maintain when some tarballs/zips, thorough instructions, and heavy tech support works fine. You're already typically paying from 10's to 100's of K up front and 1000's a month to even run real Enterprise class software anyway. Surprisingly installer tech that was designed around simple desktop apps is just not that helpful. Our installer is a guy that shows up at you office, lol.
Depends on the jurisdiction, there are contradictory precedents here. No doubt it will end up at the Supreme Court eventually. I wouldn't hold my breath for people being able to permanently remove their 'papers' from public scrutiny. The 5th exists to prevent the possibility of forced confessions. However, that danger doesn't exist here. If you're not guilty then the evidence will be exculpatory and what the evidence IS can't be changed by torturing you, therefor it is hard to argue that the individual's rights are being violated or that society's interest on the whole falls on the side of disallowing this practice.
Note that you will argue that forcing me to give out a key is coercive and you would be correct. HOWEVER coercion is not something that is forbidden to the state, as a second's reflection will amply demonstrate. It is only when that coercion would be destructive of the ends of justice and contrary to the public good that it becomes a problem.
Slashdot Mirror
Yeah, see, my own feelings are pretty much like yours. I agree with spitzak though, RMS is being ridiculous, but since when is THAT news?
Nobody says you shouldn't share them, but you're going to have to also understand that other people won't necessarily want them and have their own to share with you as well. That's all fine of course if everyone is civil about it. Things rarely remain civil in these situations however. I'd note that RMS isn't exactly known for being civil either... My point is there's nothing wrong with a tool that lets you extend your search to google or wherever. It isn't inherently bad. YOU may not like it, you are certainly entirely welcome to your opinion, its fine. However it becomes nonsensical when you start talking about something like Ubuntu being evil for providing a tool that YOU PERSONALLY don't approve of. Just don't use it. Go ahead and tell Mark Shuttleworth you aren't using it. Sure, tell him why. Just don't expect to be taken seriously when you call Ubuntu evil...
is how does Canonical present this choice. If its hard coded and not documented, that's one extreme. If it is an option you openly select with a checkbox every time that's probably the other extreme. RMS IMHO is getting all hot and bothered about the wrong things. If we CAN'T have options to interact with external services then we have NO choice, that's not freedom. He's got a fixed view of things like that, and it is just not appropriate. Its also cultural. While we can say people should be entitled to a private and a public life you're not going to find very much agreement across cultures of what that means.
Oh, there are decent newish keyboards, but honestly the feel is IMHO inferior to the good old Model M. Guess I grew up on actual Selectric typewriters and such, lol. Nothing like learning to type on an IBM cardpunch machine CA 1970...
Mine is of the very oldest vintage too. The local recycle place put out a BOX of them a few years ago. I snapped up the whole box for like $10. Still got 3 of these beasties and they're the best peripheral ever made if you ask me. Takes a bit of a stack of adapters to get to USB with the thing, but I got there...
And for you who haven't experienced the Zen of it all the lack of the 'windows' key and such crud is a blessing ;) I can do 120 WPM with this baby.
Well, I gotta say, there is less diversity out there. OTOH you really had to be doing some niche stuff even in the old days to be writing code for Novix chips, transputers, Swann systems, and such.
Crap, it may be a holy grail for x86 but only because x86 virtualization sucks so bad. Go run your stuff on a 360/Z/P series architecture and you've been able to do this stuff since the 1960s because you have 100% airtight virtualization.
Of course ANY such setup, regardless of hardware, is only as good as the hypervisor. It is still not really clear what is actually gained. Truthfully no degree of isolation is bullet proof because whatever encloses it can look at it and there will ALWAYS be some set of inputs to that wrapping layer that will subvert it.
In any case, I'm not up on L4. In my OS design days if you wanted that level of performance you simply ran in a single flat address space with relocatable code (OS9/68k for example) and then ran your security code in a separate processor.
Really depends on the CPU architecture. You can't generalize a lot about that kind of thing. TLB is invalidated in x86. I'm a little sketchy on the ARM situation, but 68k and PPC architectures have a rather different setup than x86.
Context switches between threads generally aren't as expensive, yes, because the whole point with threads is shared address space, which is primarily for this very reason. However, there are still issues with locality, instruction scheduling, etc. There ARE also often changes in addressing if for no other reason than supervisor needs different tables to specify its different permissions. Again, there are many different impacts on performance. It is really not material if this is because of a change in mode or in addressing, these are exactly the switches that microkernels amplify.
Yeah, this is true. I think if you were to start at zero and design a CPU architecture with a microkernel specifically in mind some clever things would come out of that and help even the playing field. Of course the question is still whether it is worth it at all. Until microkernels show some sort of qualitative superiority there's just no real incentive.
Uhhhhhhh, wait a minute. I was an avid Amiga programmer back in the day. AmigaOS wasn't in any particular sense a microkernel. Such distinctions in fact would be largely meaningless because AmigoOS was written to run on the MC68k processor, a chip which had no MMU nor any facilities for address translation at all (though in theory you could implement storage backed virtual memory it wasn't terribly practical). Every Amiga program was address independent, it could load and run at any address, and all software on the machine, applications and OS necessarily shared a single address space.
There was a considerable amount of message passing between AmigaOS components, but no more than you would expect to see in a modern display manager (IE like X distributes UI events as messages via the X protocol). At a low level you simply made calls into the Amiga system ROM, where pretty much all the kernel functionality was located, and/or tweaked around with hardware directly depending on how friendly your program cared to be WRT to letting other stuff run at the same time.
Most games for instance simply took over the machine and tossed the whole intuition layer out, called ROM directly, and often seized direct control of things like the Copper (advanced DMA controller basically, this drove most of the cool stuff Amiga could do). Such a program would not work at all with other software and you would only run it by itself from its own boot disk usually.
A lot of software would 'play nice' with the rest of the system and only merge its stuff into the copper list via the APIs and keep to whatever memory it was allocated. In that case you had a standard desktop type program, which could either manage an entire screen or live inside a desktop window. A lot of games ran like this, grabbing their own screen but allowing you to run other applications at the same time, return to the OS, etc. Generally productivity apps or utilities might run in actual desktop windows, in which case you would use the intuition GUI toolkit libraries.
ALL context switches are expensive. The primary effect of a context switch is that each context has its own memory address layout. When you switch from one to another your TLB (translation lookaside buffer) is invalidated. This creates a LOT of extra work for the CPU as it cannot rely on cached data (addresses are different, the same data may not be in the same location in a new context) and consequent cache invalidation, etc. It really doesn't matter if it is 'user' or 'kernel' level context, the mechanics are all the same.
All interrupts in processors are handled in a single context, the 'ring 0' or 'kernel state'. Device drivers (actual drivers that is) handle interrupts, that's their PURPOSE. When the user types a keystroke the keyboard controller generates an interrupt to hardware which FORCES a CPU context switch to kernel state and the context established for handling interrupts (the exact details depend on the CPU and possibly other parts of the specific architecture, in some systems there is just a general interrupt handling context and software does a bunch of the work, in others the hardware will set up the context and vector directly to the handler).
So, just HAVING an interrupt means you've had one context switch. In a monolithic kernel that could be the only one, the interrupt is handled and normal processing resumes with a switch back to the previous context or something similar. In a microkernel the initial dispatching mechanism has to determine what user space context will handle things and do ANOTHER context switch into that user state, doubling the number of switches required. Not only that but in many cases something like I/O will also require access to other services or drivers. For instance a USB bus will have a USB driver, but layered on top of that are HID drivers, disk drivers, etc, sometimes 2-3 levels deep (IE a USB storage subsystem will emulate SCSI, so there is an abstract SCSI driver on top of the USB driver and then logical disk storage subsystems on top of them). In a microkernel it is QUITE likely that as data and commands move up and down through these layers each one will force a context switch, and they may well also force some data to be moved from one address space to another, etc.
Microkernels will always be a tempting concept, they have a certain architectural level of elegance. OTOH in practical terms they're simply inefficient, and most of the benefits remain largely theoretical. While it is true that dependencies and couplings COULD be reduced and security and stability COULD improve, the added complexity generally results in less reliability and less provable security. Interactions between the various subsystems remain, they just become harder to trace. So far at least monolithic kernels have proven to be more practical in most applications. Some people of course maintain that the structure of OSes running on systems with large numbers of (homogeneous or heterogeneous) will more closely resemble microkernels than standard monolithic ones. Of course work on this sort of software is still in its infancy, so it is hard to say if this may turn out to be true or not.
Eh?
What's your excuse for the US, which when you count in state liabilities, etc (which you are counting with the EU countries) it is FAR FAR FAR worse off than even Greece.
Look up the term "bucket shop" for instance. It is one thing to say be a registered CFTC regulate exchange and regulated FCMs (Futures Commission Merchant), IBs, etc. In this case if I buy a gold contract THERE IS GOLD behind that contract, there is sufficient liquidity to guarantee that the trade will settle, the DTC or some other facility will insure that trades ARE settled, order flow is monitored for front running, etc etc etc. The main point there is however that the liquidity exists and that the investor is actually participating in the market.
For instance a bucket shop would simply let you 'buy' gold for instance, but in reality they would just take your money. If gold goes down and you exit the market they get to keep some of that money. If OTOH it goes up and you take your profit they can't cover it (except by raiding someone else's account). InTrade isn't participating in markets, it is just letting you 'bet', which is not the same thing. You're playing the market effectively AGAINST them.
Interestingly the only market where this effectively DOES work is spot FX. Because there is nothing but cash in FX in different currencies all FX trading IS in effect betting. Even then the US now pretty much forbids retail FX trading, the business has moved overseas.
Banks, and any depository institution falls into this category, have quite sophisticated KYC (Know Your Customer) policies in place, which are mandated by both national and international law. You would simply never be able to open an account with InTrade, period. If you think using a VPN is going to fool them, they don't even look at that kind of thing. You're going to provide them with documentation about where the money came from and who you are when you sign up. No doubt there ARE ways to skirt these procedures for small amounts of money or people who will (illegally) act as a proxy (say your cousin who happens to live in London or something) the vast majority of US citizens will just get nowhere when they try to do business with InTrade.
Nah, you have to have KYC type AML procedures in pretty much every country in order to operate this sort of business. What ACTUALLY happens is a company like InTrade says to itself "if we don't apply proper KYC and do business with US citizens then the US will do nasty things like seize our assets", and that's pretty much the end of it. Even if InTrade has no assets in the US or in US controlled banks there are actually agreements between all western countries about this sort of thing.
Oh, no doubt about it. At least in our case the thing is you probably have to start with planning at a higher level. Our customer would start by thinking about business needs, features, performance, reliability of the whole platform, and various integration needs and desires they would have. Then we would engineer them a deployment plan in conjunction with their IT people. It will be decided where the various services are deployed, are they using Kerberos, internal authz, AD, some other LDAP service, etc. for authentication. Is there external client network access required? Is it happening via a VPN, SSL, into a DMZ? If so then is there a separate server handling that, is it clustered, how is failover being handled? Do the core servers reside on the same network or on the other side of the DMZ? What about other incoming and outgoing data streams, how is high reliability being handled there? Do we have to assist in establishing SLAs? Are there extra pieces the customer needs to monitor those? There's just endless amounts of details with this stuff. It gets pretty crazy. Basically a lot of the reason we exist is to deal with all this kind of stuff, guide clients, and provide them with the information they need to make decisions and/or handle things on their own. We do have manuals, and you can definitely install the software based on the manual, but chances are you won't have a good grasp of the best ways to use it and achieve your business goals without help. I don't know how to capture all of that in any written form. I've got a large wiki, but even then you can only convey so much. A lot of it is just familiarity with the problems and knowing what kind of stuff will or won't likely work.
Isn't that the whole point, that there is no point? It is the whole pointlessness of the joke that makes it funny. You're SUPPOSED to roll your eyes.
I think what you'd find is that each install is unique enough that the effort needed to set up an install script which would have to be gone over with a fine toothed comb and tested several times just to do one or two customers wouldn't be cost effective. We've looked into these things in the past, trust me.
In fact you're probably wrong about perceptions. Everyone enjoys convenience and simplicity. Automatic installer scripts would generally convey a polished appearance, BUT our customers are our customers because of the significant savings and ability to integrate into their own business process and flexibility that our product gives them vs what they have from other vendors. Of course they'd love to pay less, but they know the deal they're getting from us is great for them and that we don't charge stupid amounts of money for nothing. All I can say is we are doing something right because business grows every year.
In Soviet Russia IKEA buy GOOGLE.
Exactly. There are just such a HUGE number of different possible things that can go into an individual setup. There are in our main 2 pieces of product each a rather extensive and tricky XML file that you're almost certain to have to do some significant surgery on. It is POSSIBLE you can set up a 'vanilla' setup for demo purposes basically, but you're sure to have to edit this beast real soon anyway.
There are other aspects too. While I say our system is a 'piece of software' it is really a number of services which can be distributed in different ways between however many machines someone needs for their purposes, and there are several ways you could do that. Depending on exactly how you actually set things up there could be various quirky setup and configuration issues. In most cases the specific setup is one that hasn't been entirely tested before or even entirely anticipated. Often you're dealing with the person that designed some part of things to know exactly how (or even if) something can be done. This is mainly because this sort of software is EARs deploying onto J2EE servers, databases (there are 4 separate schemas that we use for various things, they might well not even be on the same servers). It is just complex and ugly.
I think people get the misimpression from what I said that we aren't concerned with making things easy and smooth. That wouldn't be true. Ease of use is always a concern for any decent ISV. It is just that some issues aren't reducible to a few choices in an install wizard, and there are just factors that aren't sensible to deal with at that level. In fact there are a lot of automation scripts of various types that we use. All database updates for instance are done via a structured set of script modules that we wrote years ago. That can reduce a really complex process to a couple shell commands. Other bits of software DO have installers.
Yet another incipient genius who probably hasn't had the slightest experience on the ISV side of this equation with the convenient one-size-fits-all answer to end all answers. Thanks, that was amazingly edifying!
Frankly, you have NO FUCKING CLUE what you're talking about. I would presume you really have no familiarity with actual commercial line-of-business enterprise class software. Any enterprise which is not run by morons and is large enough to qualify as an 'enterprise' has an extensive IT infrastructure which is highly integrated and designed around an enterprise information systems architecture, involves capacity, availability, security, and usability analysis and planning etc. When you 'deploy' software into these environments, and I'm talking about large banks, Fortune 500's, large international corps mainly there's no such thing as "drop the installer on a hard drive and run it". You're dealing with integrated management systems, enterprise-wide credentials and role management, complex licensing situations, other corporate IT policy issues, etc etc etc. The idea that MY software, which handles transactions from generally 1000's of clients and integrates with easily on average 4-5 other complex software stacks is 'lacking an installer' because you don't install it clicky--click is hilarious.
You can think what you want, but at least in my world 'enterprise software' means something very different from what some people seem to be using it for. This is not like in your typical small business environment where you slap up a copy of Apache and install Trac on it and call it a day (and even there I'll note there's no single installer that can handle setting that up for you).
Because most Enterprise software (and I manage a product line which is definitely in this category) isn't something so simple that you can install it with RPM or Installshield (or whatever the heck MS calls it now). There are multiple interacting services, very specific dependencies for things that are often not packaged at all for the target platform and usually cannot be distributed, etc. Complex databases, usually on other machines, have to be set up, XML files edited, etc to even create a basic working environment for our software. Now, MOST things might not be quite this complicated, but I suspect most software that you have to install largely by hand has many of these kinds of issues. Most of this stuff has to integrate fairly deeply with the client's IT infrastructure and setting up the basic applications is only a small part of it.
In our case we have some installers for some specific tools, but the main product? No, it wouldn't materially assist in setup and would just be yet another task to maintain when some tarballs/zips, thorough instructions, and heavy tech support works fine. You're already typically paying from 10's to 100's of K up front and 1000's a month to even run real Enterprise class software anyway. Surprisingly installer tech that was designed around simple desktop apps is just not that helpful. Our installer is a guy that shows up at you office, lol.
Depends on the jurisdiction, there are contradictory precedents here. No doubt it will end up at the Supreme Court eventually. I wouldn't hold my breath for people being able to permanently remove their 'papers' from public scrutiny. The 5th exists to prevent the possibility of forced confessions. However, that danger doesn't exist here. If you're not guilty then the evidence will be exculpatory and what the evidence IS can't be changed by torturing you, therefor it is hard to argue that the individual's rights are being violated or that society's interest on the whole falls on the side of disallowing this practice.
Note that you will argue that forcing me to give out a key is coercive and you would be correct. HOWEVER coercion is not something that is forbidden to the state, as a second's reflection will amply demonstrate. It is only when that coercion would be destructive of the ends of justice and contrary to the public good that it becomes a problem.