Ah, more (ab)use of The Car Analogy, how about this.
A computer is like a car - the passenger cabin is user space, the engine and drivetrain are the kernelspace, the wheels are drivers. A monolithic kernel is like if all the tyres were connected by hoses - if 1 tyre blows, they all go flat and the car crashes spectacularly. A microkernel has each tyre inflated seperately, if 1 blows the car can be pulled over. If there were enough wheels, 1 blowout is inconsequential. Run flat tyres can be considered a workaround. In the extreme, an electric car with a hub motor for each wheel further increases the provable resiliance, but as with microkernels - performance traditionally sucks.
The only reason that Linux isn't viable on the desktop is because Microsoft locks people into their proprietary standards
Nonsense, Microsoft's proprietry lockin is one of the reasons that Linux is yet to make it on the desktop. There are others such as inertia, lacking hardware support & lacking software support.
Of course all of this depnds on your idea of 'the desktop' and 'make it'.
" Note that Rekall does not include an RDMS -- it's only a front-end."
Done? I think not.
MS Access is 'only' a frontend to JET (aka MDB). It's just a very tightly coupled frontend.
Rekall like most Unix software is designed to be loosely coupled with other components. Choose your own backend. If you don't like Rekall, might I suggest Knoda (which I believe can do a one-file-forms-n-all app), Glom (postgresql only, but tightly coupled) or OpenOffice.org Base.
Of course none of them are as ubquitous as MS Access.
I came across this recently, similar to Aardvark. It's CSSViewer which shows in a (large) tooltip, the css applied to an element over which the mouse is hovering.
I found it very useful for closing the loop between code and result.
My sister got one of these, to my surprise, the fox was there.
There is an icon on the desktop, along with Internet Explorer's and about 30 others. I believe Internet Explorer came as default, but I didn't observe the first seconds directly.
It seems a standard install, no obvious branding or skinning - the start page has been set to Dell's EULA.
Neither browser masks the other that I can tell, of course each has it's standard 'I'm not the default' message.
The $notnerd isn't maintaining the system. Precise meaning has really come back, to bite me on the arse in this thread.
A non-techie most often gets the final decision about which solution to choose. They base their decision on advice from their in house techies, sales pitches and bids received etc.
One pitfall they wish to avoid, is a system that is more expensive to maintain and customise in the long term. A solution-in-a-box is commonly held to have lower staffing overhead, because less experienced (aka cheaper) techies, or even laypersons can operate it and perform day to day admin. With an in house solution (bespoke or scripted generic services), the staffing cost is deemed higher; because deeper site knowledge and greater experience is needed.
Note that this excludes the cost of customising and long term maintaing the system. Any manager doesn't want to rely exclusively on a small, hard to recruit pool of talent.
I should have said 'because they don't understand or care about the technology as we do, only the results'.
Turnkey is sometimes a good choice, such as in the cases you give. Customised packages & bespoke are sometimes a good choice sometimes.
My argument (and I believe Dolda2000's argument), is that turnkey solutions should not be monolithic. They should be built on independant components, rather than being a take it or leave it lump.
Any solution (eg Active Directory, OpenLDAP+PAM+Kerberos+mgmt interface) will be internally complex - the value added by making it turnkey is to hide the complexity.
If indeppendant components are chosen, it's much easier to adapt the solution to new requirements. If necessary, it becomes possible to step behind the scenes and change things in a way the vendor didn't intend and so didn't provide an API/interface for.
Sorry for my poor choice of phrase. What I meant was "person who at the time is uninterested in the technology, beyond how it can further their ends". I chose $notnerd because, in my experience, it's often the case when a monolithic solution-in-a-box is chosen.
I'm not arguing against turnkey, I'm arguing for technically sound solutions. In my eye that means both a strong GUI (for everyone doing one off tasks) and a strong scriptable interface (for automating repetitive tasks). Having a scriptable interface often means a CLI one, but not always).
Commercial, monolithic SSO solutions tend to have a strong GUI, and a weaker sctipting interface. Open source and in house SSO solutions tend to have a strong scripting interface and a much weaker GUI.
Hopefully this release will have both, if so, then the next job will be marketting it.
Ah, looks like we're both arguing the same side of the coin.
As you say, the turnkey solution should be a customisation of general parts, possibly tweaked to integrate with one another. The trick is getting a $notnerd to see this, marketting this solution so they choose it over Active Directory or ZENWorks. Consultants choosing and recommending it one good method.
I believe this identity solution should be delivered like any other opensource project. A source package which distributions can repackage and integrate. If the dependances are complex enough (like GNOME), someone will release a build helper (like Garnome). Fedora Directory Server may be exactly it
As an administrator, I know what you mean about scripts making inhouse work "more or less" turnkey. However, my experience is that I only have time to make the script perform the first 90% of the job - there are too many other demands on my time. A dedicated package could better address the second 90%, which includes documentation and the corner cases that need special treatment.
There is a spectrum, from monolithic 'solution', to bespoke. This implys a tradeoff, between base complexity (due to being a generalised behemoth) and installation complexity (due to bespoke in-house development).
I agree that the current crop of closed source turnkey solutions can only be customised so far. I believe a turnkey solution based on open source components could be customised further. A completely bespoke solution could be taken the furthest, but would be hardest to support.
Maybe this is just me, but I've never understood why people need "turnkey solutions" for things like these.
Largely, I think it boils down to - 'because they don't understand the technology as we do'. Take a simple, high level requirement: identity management. You or I might see that in terms of the components: such as a directory, an authentication service, creation & removal scripts, some means of replication, monitoring scripts etc.
A $notnerd sees the requirement as a black box, they don't care about the internals. They've probably been told by some techie/salesman that it will address some problem they have. For this person turnkey seems perfect, $company sells $product which is billed as an 'identity managment solution'. A magic black box solution to a black box problem, their work is done - now it is IT's problem.
Updating your LDAP, Kerberos, NSS and PAM configs manually isn't exactly hard as it is. If you want to make it easy to set up multiple workstations with this setup, just use Kickstart (or a shell script on NFS...).
To you it isn't, but what happens when you leave? It's much easier to recruit someone to maintain a push button solution, than a partly bespoke ecology of components and scripts. Often the solution and the ecology are similar in complexity, but the solution hides that behind a GUI and glossy marketting material.
Purchasers often chose to spend their money on specialised software (solutions), hopefully saving time. We often choose to spend our time customising general purpose software, hopefully saving money.
Without quoted statistics this reply is of course conjecture, as is yours.
I believe very few people enjoy the act of day to day driving, sports cars are a minute proportion of road traffic. What I and many others enjoy is the comfort and convenience of using a private car to travel. Auto-drive cars can increase these benefits by the following:
- Removing requirement for continuous, dedicated, concious control. Instead, read slashdot or watch I Robot as you travel to work.
- Removing necessity for private vehicle ownership, instead rent use of a class of vehicle - no need to find parking, drive straight to your destination, get out and the car will route/drive itself to a holding area or pickup.
- Safer my faith in computer control is greater then my faith in millions of bored, distracted humans. Provided the system is built up over time, slowly, a few features integrated to a trusted (proven) platform at each revision, as cars today are develop.
- Faster, with many vehicles coordinating with one another, it should be possible to increase thoughput and aggregate speed. As you say these will be mitigated by human and other uncooperative (incompatible) drivers. But it shouldn't be all or nothing.
Auto-drive cars won't appear overnight - enabling features will accrue over years - Sat Nav, cruise control, rangefinding sensors, lane drift alarms, drive by wire, braking assistance, ubiquitous wireless communication etc.
The interest, at least for myslef is not in the database engine - there are plenty of those, as you know.
The killer feature I'm looking for is a RAD for creating a good database frontend. Basically, can OOo Base surpass MS Access by combining powerful data aware components + object model, a good IDE, switchable backends & portable runtime with a report engine.
That was my reaction also. TFA refers to the BSA letter containing DHCP as an example, so it's probably in there; but a quick google search turned up no obvious references to patents on DHCP - only some that use it.
Sorry to go off topic, and feel free to ignore this.
What is your experience of Linux desktop GIS? What software do you use (other than postgis, mapserver, gdal et al at wifimaps.com)? I most curious what GUI map visualiser/editor (if any) that you use.
Avoiding vendor lockin is of course A Good Thing. However, as others have said, there is no format completely vendor neutral - each platform has it's own set of unique features that don't translate directly and must be stored somewhere in an extension or custom tag. I'm certain the OASIS/OOo format has a few StarOfficeisms in it.
What matters is that the data you own is readly transformable into a Fully Open and documented format independant of your chosen platform, normally (but not necessarily) this will mean your native format is Fully Open and documented. This includes all data, styling, formatting, metadata and interrelationships. Bascially you should be able to quickly jump ship, even if your vendor has been wiped of the earth or there are legal/technical issues preventing you from running the original platform, without loss or 'damage' of any information. There must be at least one other clear route to all your information, completely bypassing the original platform.
As an example.doc would be unsuitable since the format is undocumented and you would be reliant on the correct version of office to correctly and completely read/export it, hence you would depend on Microsoft.
Similarly prior to it's released as open source software and even immediately after.sxw would have been unsuitable (even though it was 'just zipped xml'), since OOo/StarOffice were the only way of performing any completely trustworthy export. Now the format is formally documented and independant tools exist it is suitable.
There are grey areas such as databases, which have no common datafile format but do expose Fully Open interfaces such as ODBC or JDBC.
With this in mind I would argue that forcing everyone to save documents in 'basic' formats such as HTML and RTF is counterproductive, they lack wide support for features such styling and precise page layout. Any format will do as long as you can readily, fully & demonstratably extract all your information, independantly of the platform that created it.
I didn't follow the NT line back then, but from the stories I've heard MS said SP4 would be the last one made, thrn, eventually they released 5, 6 & 6a. Can anyone from the period confirm this?
My personal view is the marketting dept will have had a hand in this, Win 2K is now nothing but a cost to Microsoft. The more customers they can convince to upgrade through uncertainty about maintenance the better. However we'll end up with SP5 shortly, due to 'good will' and 'popular demand'
Alex
PS Having said all that, Microsoft's support periods are greater than most Linux distributors - 5 years+ for MS Windows vs 3 years for SLES or RHEL.
Initial rumors about 3.5 GHz PowerPC chips are fine and dandy... but, as of right now, IBM simply can't produce them. If the Xbox 2 goes with the PowerPC architecture, it might be at the 2.0-possibly as high as 3.0 GHz mark, depending on the price of the chips and the rest of the system components.
Interesting, I wasn't aware of PowerPC having trouble with clockspeed ramp up, although it stands to reason.
My point was more that due to the subsidies & economies of scale the Xbox could make a very cheap cluster node, even at 2.0 GHz.
Going by other murmurings and apparent leaks, the Xbox 2 will be based around a customised 3.5 GHz Power PC CPU, including 128bit vector processing units. This architecture is much more effective than x86 for raw processing.
The interview talks of a sensible price being $299 or even $199, with subscription services providing a subsidy.
This (provided one can bypass whatever DRM lockdown is slapped on), could make the Xbox 2 a very cheap way of doing high performance clustered computing.
Alex So in summary (this being slashdot): Imagine a Beowulf cluster of those... when will it run Linux?
It would just take a bit of cooperation with the filesystem programmers - add a shred() function or suitable IOCTL to the API in a backward compatible manner. When the context menu is constructed, check the filesystem supports the shred feature and enable or disable the menu item as needed.
Slashdot Mirror
Sorry, that line was meant for added humour. I wish my car was a Hywire.
Ah, more (ab)use of The Car Analogy, how about this.
A computer is like a car - the passenger cabin is user space, the engine and drivetrain are the kernelspace, the wheels are drivers. A monolithic kernel is like if all the tyres were connected by hoses - if 1 tyre blows, they all go flat and the car crashes spectacularly.
A microkernel has each tyre inflated seperately, if 1 blows the car can be pulled over. If there were enough wheels, 1 blowout is inconsequential.
Run flat tyres can be considered a workaround. In the extreme, an electric car with a hub motor for each wheel further increases the provable resiliance, but as with microkernels - performance traditionally sucks.
Abusive enough for you?
Nonsense, Microsoft's proprietry lockin is one of the reasons that Linux is yet to make it on the desktop. There are others such as inertia, lacking hardware support & lacking software support.
Of course all of this depnds on your idea of 'the desktop' and 'make it'.
MS Access is 'only' a frontend to JET (aka MDB). It's just a very tightly coupled frontend.
Rekall like most Unix software is designed to be loosely coupled with other components. Choose your own backend. If you don't like Rekall, might I suggest Knoda (which I believe can do a one-file-forms-n-all app), Glom (postgresql only, but tightly coupled) or OpenOffice.org Base.
Of course none of them are as ubquitous as MS Access.
I came across this recently, similar to Aardvark. It's CSSViewer which shows in a (large) tooltip, the css applied to an element over which the mouse is hovering.
I found it very useful for closing the loop between code and result.
I'm sure you mean this in jest. However, the folks at mdbtools are working on it.
Alex
Ditto, I had to do a doubletake on that headline.
That is precisely what was meant, as demonstrated by this beauty:
_ weakest_lin.html
http://www.schneier.com/blog/archives/2005/02/the
My sister got one of these, to my surprise, the fox was there.
There is an icon on the desktop, along with Internet Explorer's and about 30 others. I believe Internet Explorer came as default, but I didn't observe the first seconds directly.
It seems a standard install, no obvious branding or skinning - the start page has been set to Dell's EULA.
Neither browser masks the other that I can tell, of course each has it's standard 'I'm not the default' message.
The $notnerd isn't maintaining the system. Precise meaning has really come back, to bite me on the arse in this thread.
A non-techie most often gets the final decision about which solution to choose. They base their decision on advice from their in house techies, sales pitches and bids received etc.
One pitfall they wish to avoid, is a system that is more expensive to maintain and customise in the long term. A solution-in-a-box is commonly held to have lower staffing overhead, because less experienced (aka cheaper) techies, or even laypersons can operate it and perform day to day admin. With an in house solution (bespoke or scripted generic services), the staffing cost is deemed higher; because deeper site knowledge and greater experience is needed.
Note that this excludes the cost of customising and long term maintaing the system. Any manager doesn't want to rely exclusively on a small, hard to recruit pool of talent.
Sorry, I've chosen my words poorly. Again.
I should have said 'because they don't understand or care about the technology as we do, only the results'.
Turnkey is sometimes a good choice, such as in the cases you give. Customised packages & bespoke are sometimes a good choice sometimes.
My argument (and I believe Dolda2000's argument), is that turnkey solutions should not be monolithic. They should be built on independant components, rather than being a take it or leave it lump.
Any solution (eg Active Directory, OpenLDAP+PAM+Kerberos+mgmt interface) will be internally complex - the value added by making it turnkey is to hide the complexity.
If indeppendant components are chosen, it's much easier to adapt the solution to new requirements. If necessary, it becomes possible to step behind the scenes and change things in a way the vendor didn't intend and so didn't provide an API/interface for.
Also agreed.
Sorry for my poor choice of phrase. What I meant was "person who at the time is uninterested in the technology, beyond how it can further their ends". I chose $notnerd because, in my experience, it's often the case when a monolithic solution-in-a-box is chosen.
I'm not arguing against turnkey, I'm arguing for technically sound solutions. In my eye that means both a strong GUI (for everyone doing one off tasks) and a strong scriptable interface (for automating repetitive tasks). Having a scriptable interface often means a CLI one, but not always).
Commercial, monolithic SSO solutions tend to have a strong GUI, and a weaker sctipting interface. Open source and in house SSO solutions tend to have a strong scripting interface and a much weaker GUI.
Hopefully this release will have both, if so, then the next job will be marketting it.
Ah, looks like we're both arguing the same side of the coin.
As you say, the turnkey solution should be a customisation of general parts, possibly tweaked to integrate with one another. The trick is getting a $notnerd to see this, marketting this solution so they choose it over Active Directory or ZENWorks. Consultants choosing and recommending it one good method.
I believe this identity solution should be delivered like any other opensource project. A source package which distributions can repackage and integrate. If the dependances are complex enough (like GNOME), someone will release a build helper (like Garnome). Fedora Directory Server may be exactly it
As an administrator, I know what you mean about scripts making inhouse work "more or less" turnkey. However, my experience is that I only have time to make the script perform the first 90% of the job - there are too many other demands on my time. A dedicated package could better address the second 90%, which includes documentation and the corner cases that need special treatment.
There is a spectrum, from monolithic 'solution', to bespoke. This implys a tradeoff, between base complexity (due to being a generalised behemoth) and installation complexity (due to bespoke in-house development).
I agree that the current crop of closed source turnkey solutions can only be customised so far. I believe a turnkey solution based on open source components could be customised further. A completely bespoke solution could be taken the furthest, but would be hardest to support.
Largely, I think it boils down to - 'because they don't understand the technology as we do'. Take a simple, high level requirement: identity management. You or I might see that in terms of the components: such as a directory, an authentication service, creation & removal scripts, some means of replication, monitoring scripts etc.
A $notnerd sees the requirement as a black box, they don't care about the internals. They've probably been told by some techie/salesman that it will address some problem they have. For this person turnkey seems perfect, $company sells $product which is billed as an 'identity managment solution'. A magic black box solution to a black box problem, their work is done - now it is IT's problem.
To you it isn't, but what happens when you leave? It's much easier to recruit someone to maintain a push button solution, than a partly bespoke ecology of components and scripts. Often the solution and the ecology are similar in complexity, but the solution hides that behind a GUI and glossy marketting material.
Purchasers often chose to spend their money on specialised software (solutions), hopefully saving time. We often choose to spend our time customising general purpose software, hopefully saving money.
Alex
Without quoted statistics this reply is of course conjecture, as is yours.
I believe very few people enjoy the act of day to day driving, sports cars are a minute proportion of road traffic. What I and many others enjoy is the comfort and convenience of using a private car to travel. Auto-drive cars can increase these benefits by the following:
- Removing requirement for continuous, dedicated, concious control. Instead, read slashdot or watch I Robot as you travel to work.
- Removing necessity for private vehicle ownership, instead rent use of a class of vehicle - no need to find parking, drive straight to your destination, get out and the car will route/drive itself to a holding area or pickup.
- Safer my faith in computer control is greater then my faith in millions of bored, distracted humans. Provided the system is built up over time, slowly, a few features integrated to a trusted (proven) platform at each revision, as cars today are develop.
- Faster, with many vehicles coordinating with one another, it should be possible to increase thoughput and aggregate speed. As you say these will be mitigated by human and other uncooperative (incompatible) drivers. But it shouldn't be all or nothing.
Auto-drive cars won't appear overnight - enabling features will accrue over years - Sat Nav, cruise control, rangefinding sensors, lane drift alarms, drive by wire, braking assistance, ubiquitous wireless communication etc.
Thats my optimistic view, anyway.
Regards
Alex
Starting with this search: audio diskette, 1981-1988
Lead me to posts regarding compusonics who patented and marketted such a technology. Although whether it was analouge is questionable.
Regards, and I'd please let us know any outcome.
Alex
2. Use HTP: HTTP Time Protocol
The interest, at least for myslef is not in the database engine - there are plenty of those, as you know.
The killer feature I'm looking for is a RAD for creating a good database frontend. Basically, can OOo Base surpass MS Access by combining powerful data aware components + object model, a good IDE, switchable backends & portable runtime with a report engine.
Alex
That was my reaction also. TFA refers to the BSA letter containing DHCP as an example, so it's probably in there; but a quick google search turned up no obvious references to patents on DHCP - only some that use it.
Anyone have a link to the BSA's letter itself?
Sorry to go off topic, and feel free to ignore this.
What is your experience of Linux desktop GIS? What software do you use (other than postgis, mapserver, gdal et al at wifimaps.com)? I most curious what GUI map visualiser/editor (if any) that you use.
With thanks for your time.
Alex
Avoiding vendor lockin is of course A Good Thing. However, as others have said, there is no format completely vendor neutral - each platform has it's own set of unique features that don't translate directly and must be stored somewhere in an extension or custom tag. I'm certain the OASIS/OOo format has a few StarOfficeisms in it.
.doc would be unsuitable since the format is undocumented and you would be reliant on the correct version of office to correctly and completely read/export it, hence you would depend on Microsoft.
.sxw would have been unsuitable (even though it was 'just zipped xml'), since OOo/StarOffice were the only way of performing any completely trustworthy export. Now the format is formally documented and independant tools exist it is suitable.
What matters is that the data you own is readly transformable into a Fully Open and documented format independant of your chosen platform, normally (but not necessarily) this will mean your native format is Fully Open and documented. This includes all data, styling, formatting, metadata and interrelationships. Bascially you should be able to quickly jump ship, even if your vendor has been wiped of the earth or there are legal/technical issues preventing you from running the original platform, without loss or 'damage' of any information. There must be at least one other clear route to all your information, completely bypassing the original platform.
As an example
Similarly prior to it's released as open source software and even immediately after
There are grey areas such as databases, which have no common datafile format but do expose Fully Open interfaces such as ODBC or JDBC.
With this in mind I would argue that forcing everyone to save documents in 'basic' formats such as HTML and RTF is counterproductive, they lack wide support for features such styling and precise page layout. Any format will do as long as you can readily, fully & demonstratably extract all your information, independantly of the platform that created it.
Alex
I didn't follow the NT line back then, but from the stories I've heard MS said SP4 would be the last one made, thrn, eventually they released 5, 6 & 6a. Can anyone from the period confirm this?
My personal view is the marketting dept will have had a hand in this, Win 2K is now nothing but a cost to Microsoft. The more customers they can convince to upgrade through uncertainty about maintenance the better. However we'll end up with SP5 shortly, due to 'good will' and 'popular demand'
Alex
PS Having said all that, Microsoft's support periods are greater than most Linux distributors - 5 years+ for MS Windows vs 3 years for SLES or RHEL.
Interesting, I wasn't aware of PowerPC having trouble with clockspeed ramp up, although it stands to reason.
My point was more that due to the subsidies & economies of scale the Xbox could make a very cheap cluster node, even at 2.0 GHz.
Going by other murmurings and apparent leaks, the Xbox 2 will be based around a customised 3.5 GHz Power PC CPU, including 128bit vector processing units. This architecture is much more effective than x86 for raw processing.
The interview talks of a sensible price being $299 or even $199, with subscription services providing a subsidy.
This (provided one can bypass whatever DRM lockdown is slapped on), could make the Xbox 2 a very cheap way of doing high performance clustered computing.
Alex
So in summary (this being slashdot): Imagine a Beowulf cluster of those... when will it run Linux?
It would just take a bit of cooperation with the filesystem programmers - add a shred() function or suitable IOCTL to the API in a backward compatible manner. When the context menu is constructed, check the filesystem supports the shred feature and enable or disable the menu item as needed.