BTW: When he said, "just do it", he's not talking about informing management; he's talking about informing/surveying USERS. He's meaning, "Don't bother trying to convince users, instead, just tell them the procedures have changed, and this is 'The New Way' (TM) to do things. They'll do it, find it better/faster, than thank you"
Shamelessly stolen, so don't mod me up.
Mark T. Uemura (IP 221.249.159.51) (mark.uemura@gmail.com) on Tue Oct 25 14:18:17 2005 (GMT)
It's unfortunate that reporters such as this guy would sensationalize a talk by carefully crafting his story from bits and pieces mostly taken out of context. So, in all fairness to my firm and to those who were not present, I feel compelled to set the story straight.
First off, the story is not an interview even though it may come across as such. The title is rather sensational but I certainly wasn't desperate. There were problems and they were fixed and our team was just very resourceful in doing so.
Gedda writes: > IT managers who want to deploy an open source solution but are worried > about company politics should go ahead and do it without asking, > according to PricewaterhouseCoopers (PWC) Japan IT manager Mark Uemura.
No, this is taken out of context. What I said was that we had very big and important changes that we needed to make in order to restore network and application stability. My reference to just going ahead and doing it referred to making the necessary changes behind the scenes. It wasn't about company politics and it wasn't about migrating services from Windows to OpenBSD. My experience was that we did ourselves a disfavour by trying to inform and explain to users and management the technical reasons for the changes that needed to be made. In fact, all of the pushback had nothing to do with OpenBSD. We needed to migrate from an old Domain Controller with a corrupt Active Directory to a new one. We also introduced the concept of working on Application Servers in Terminal Services to take advantage of server power for resource intensive applications that ran very slowly on users' PCs. So, the push back was related to things like "you'll have to login to this new Domain rather than the old one from tomorrow onwards." or getting users to change the way they work and use applications running on a Terminal Servers for speed. In the end, when all was sad and done, users and management realized the difference that we had made; no more downtime or data loss. Furthermore, they've never had everything running so smoothly and as efficiently for as long as they could remember. Their IT problems went away as a result of our efforts and the decisions that we made.
In fact, all of the migrations to OpenBSD were either behind the scenes where the users were oblivious to the changes. Well, almost oblivious. Often times we would get "Hey, the Internet is really fast today, cool!" or "Man, can you guys like spill some coffee in the server room or something? We're not used to this much uptime. It means we can't go home early anymore!"
In those cases where users did have to interact with OpenBSD, it was always well received and positive such as moving off of a very slow VPN for remote access on to a quicker and more user friendly alternative such as port forwarding applications through OpenSSH.
> Faced with an unreliable network, Uemura went ahead and migrated systems > from Windows to OpenBSD on the premise that management would trust his > judgement.
Once again, migrating services to OpenBSD was not an issue. So long as we did not compromise security in doing so. Generally, we did so to improve security and that's what OpenBSD is famous for and yet ther
How long did it take Mozilla to get to 1.0? How long did it spend in alpha, then beta?
Beta means that the project is starting to look like a finished product, or, at least the developers have figured out the basic 'specs' for the finished product. Don't knock it; OpenSource projects generally have a pretty high quality 1.0, while many companies (MS *ahem*, AOL *ahem*) release CRAP for version 1.0
Compile? I have NO idea how to compile Wine on a 64-bit system. I cannot get it to work.
I've spent a LONG time trying to do so, and I've not been able to find anyone to point me in the right direction.
That being said, the 32-bit binaries work brilliantly on any 'modern' 64-bit linux. I suspect this doesn't include debian;-)
I only really run SuSE, but the latest 32-bit Wine installs without a hichup, and everything works exactly as it would under a 32-bit install (I'm using a 64-bit kernel).
I'm not sure how other distributions do it, but SuSE installs the 64-bit libraries alongside the 32-bit ones, points 64-bit apps at lib64, and everything 32-bit seems to work perfectly. I've heard you can acheive the same effect using a chroot 32-bit install on a 64-bit debian, but I've never tried.
World of Warcraft, Half-Life 2, City of Heroes, and many other games work properly under Cedega, Transgaming's version of Rewine (the BSD wine).
Wine?
Yes.
Wine main has quite a few DirectX features properly implemented, and Oliver Steiver (sp?) is implementing many Direct3D 9 features (like pixel shaders, etc. ..) in DX9WINE, which has been integrated into the Wine CVS tree.
So yes, its been done, and yes, a lot of stuff works. Cedega gives me my gaming fix in Linux. I've currently got Eve Online, Secondlife, Half Life 2, Age of Wonders, World of Warcraft, and some other titles I don't play much installed. Works great.
Well, the problem with Win32 is that much of it is unknown territory:) It's difficult to implement something that is completely undocumented while being quite as huge as Win32.
Also, certain things are unimplementable, but also don't work in modern Windows anyways. VxDs, for example, often break in XP. Multi-user support doesn't make much sense, given that each Wine 'install' (/home//.wine/) is single user.
The amount of implemented 'stuff', however, is quite telling, especially considering that the latest and greatest Office suite (2003) runs on Wine now.
Also, notice the update date on the status page? August 16, 2005 . . . . I know that the Direct3D stuff has come a LONG way; the status page lists d3d8 as 10% done, while in reality, d3d9 is almost there. Especially true with the gaming 'stuff', but also for general cases, support is app driven. 'X' app breaks because 'Y' function isn't implemented yet. So someone picks it up. Combined with a few general architechtural changes (like the Installshield stuff), you get 90% app support. Remaining work is completed on an as-needed basis. The flip-side of this process is that you get up to speed on new stuff coming down the MS pipeline.
To your second question. "Beta". What does it mean?
Beta means 'feature freeze'. Wine, as a Win32 API implementation for Unix, is useful now. You can run IE, Office 2003, Google Earth, Picasa, Photoshop, and a boatload of other popular apps. (Quickbooks, etc. ..). In order to keep it working for that stuff, it makes sense to stop generating new implementations, and work out as many of the bugs as possible. Thus, nothing to revolutionary will be accepted into the tree between now (beta) and 1.0 (release). Patches between now and then will focus on making sure existing functionality works properly. Once 1.0 happens, new features can be implemented on an as-needed basis.
So far, in 'alpha', the Wine developers were not afraid to break major parts of the API. Often, a snapshot would be almost unusable, or break dozens of applications. This is necessary when certain sections of the code had to be ripped out and reimplemented.
Now that Wine is getting more and more functional/useful, this development methdology will have to change. With release, it'll be safe for Linux distributions to list support for certain Windows applications using the free implementation of Wine. That'll be quite a coup if you think about it. 'Includes Wine 1.0, support for Office 2003, Internet Explorer 6, Adobe Photoshop CS, etc, etc. ..'
I imagine the Wine 1.0 tree will continue to receive bug/security updates along side newer versions.
The end vision of the Wine project is not emulation layer. The end vision of the Wine project is a fully functional UNIX app API, alongside things like QT/KDE, or GTK2/Gnome. Moving out of the haphazard alpha state of the project is a necessary step in its maturity.
We already have _several_ package management schemes that work across distributions AND desktop environments.
Autopackage is extremely user friendly, for example. Apt works most everywhere (deb, rpm, tgz distributions) SMART takes that integration work to another level (http://labix.org/smart) klik:// is super-duper friendly for end users, and even with the K its being taken to gnome.
We don't need new technology. We need the existing technology to be made more wide ranging.
SMART builds on RPM/DEB/APT/TGZ systems, abstracting package management at a high-level. You can still use the 'older' tools, however. Think server.
klik:// is far easier installs for the end-user, and the klik:// architecture is mostly distribution agnostic.
Autopackage is very intelligent about putting whatever is needed whereever its needed, and fairly distribution agnostic.
The job of the LSB should be to push these standards, and make documentation avaliable so that these tools can work everywhere. Also, to make it _far_ easier to build packages that autoconfigure themselves for any distribution, and correctly setup dependencies for the appropriate package manager.
The best thing about building newer package management tools on older framework is that you don't have to change anything; you can keep doing what you are doing, or you can move on to the 'smarter' tools. If you build a flexible enough API, it doesn't have to be targetted at _any_ framework. You build tools into the desktop environment to support whatever package management scheme you could possibly desire, or you just rely upon integration with older standards to remain sane. In fact, proper standardization on flexible package management could actually encourage MORE variety in Linux desktop environments. If there's a standard way to handle installed apps and dependancies you don't have to do as much work in your desktop environment.
Flexibility thrives in an environment of sophisticated, easy to use tools. Look at all the work distribution creators have had to do to get their gnome and KDE to 'integrate'. If both can suddenly hook into a distribution agnostic app management system, you can provide more choice in environment at a far lower integration cost.
Regarding desktop/server distinction; that's simple. RPM/APT whatever isn't going away. The newer 'layers' are RPM/APT aware. Server/Desktop common software is managed at this level, using RPM/APT. Other utilities build on top of these; they transparently manipulate RPM/APT, using pretty GUI one-click install tricks, this, that, and the other. The only 'separation' is increasing layers of complexity.
Really, the only thing that will go away is unmanaged source-installs, because they really don't make any sense. It's very difficult to manage source-installs in a package managed world; there are a few utilies that will 'wrap' sourceinstalls into an RPM or a DEB, but you still have to do dependencies and the like by hand../configure, make, make install time has passed.
RPM isn't _that_ bad, however, its not all that great, either.
No conditional dependencies, for one. Difficulty in building multiplatform RPMs, for two.
There are alternative software distribution systems that do this better. Like autopackage, or dare I say klik://
The best of both worlds is an alternative package system that customizes for your system, and wraps the necessary-bits-to-be-installed in an RPM at the last minute. That way, you can install using, say, Autopackage, or plain source, and remove the RPM when you don't need it anymore.
I think its Kdesourceinstall does that, I can't remember the proper name of the package right now.
klik://, however, will make all these issues go away if it catches on. klik:// style packaging is the future of software distribution.
Well, if its a small company, writing an uncomplicated driver, than the opensourcing the "spec" means that the guy sitting next to the guy designing the board simple puts his work online somewhere:)
SiS started to do that kind of thing, but they were so hopelessly behind in their release schedule that it was just silly.
Well, for the enterprise, there is no problem buying Crossover Office, or even Transgaming (not that you'd need gaming in the enterprise).
For the home user, Crossover Office is available for _free_, since the roll all of their improvements into Wine CVS before they integrate them into Crossover Office. Pro support costs money; again, you have to pay for that with windows. Plus, winehq.org free support is pretty awesome.
Transgaming costs $5 a month, with a three month minimum. You can also download it for free; however, given that their support is _really_ good, I'd think its worth it. Some distributions have taken to licensing both Transgaming's Cedega & Crossover Office, and including them in; I suspect thats the future.
Either way, even if you buy both ($35 + $15), you are still below the OEM cost of a Windows install; and you aren't even including the cost of spyware & viruses, either in removal software or lost time.
How many leaders of tech companies are truly tech geeks? Actually, many.
A majority of non-fortune 500 companies that have substantial growth are run by geeks. Go look at finance.yahoo.com
A fair number of fortune 500 companies that have substantial growth are also run by geeks, too.
Don't just consider 'companies'. Look at 'growing' companies.
Google. Apple. Redhat. Even if some of these leaders have become less 'geeky' over time, its just a combination of leadership plus geek. Not pure-mba goodness.
One could even say this about Michael Dell, an excellent example of a 'leader' type.
As a layman's engineer, with many 'true' engineers as co-workers, what you are saying couldn't be further from the truth.
Apple's designs are generally over-engineered (The Cube was not). Power supplies are more than 'sufficient', heat issues and the like are very well considered.
Not so in Dell designs. Desktops, or laptops. I've owned several, my company _used_ to purchase them, and they are of *crap* quality.
The 3 inspiron 8200s we owned, in particular, literally fell apart. Screws were loose, and the systems began to rattle. I've _never_ seen this on a Powerbook.
I say this as a person who builds his own systems, and runs Linux (SuSE-10.0) everwhere I can. Mac OS X is quite a nice OS, and its Unix guts are pleasantly arranged. I *do* prefer Linux; however, there is a HUGE middle ground between the 'tech savvy' and the 'artstic technophobe', and OS X fills that marketspace (i.e., the MAJORITY) nicely.
A well-known, convicted monopolist releases buggy, unreliable software.
A well-known, convicted monopolist then seeks to sell a 'protection' service to keep said buggy, unreliable software working, and much of the media sees this as a boon.
A well-known, convicted monopolist releases 'leaks' of a 'Next-Generation' operating system, whose primary features are a new GUI, whose primary characteristics change substantially between each set of 'leaks'. Yet every tech journalist and their mother OOHs and AAHs these 'leaks'.
A well-known, convicted monopolist releases 'interviews' with the characteristics of a press release, discussing how growing markets represent a grand opportunity for the company. This same company, whose 'Next-Generation' operating system is extremely late and feature triaged to the point of unrecognition, is portrayed as setting itself up for a 'win' in that it will 'beat' current market leaders by providing features they've provided for years.
Yep; tech journalists are biased. Mr. Dvorak, please keep telling me about how Apple is doomed; it gives me a great way to discredit you with any PHBs who might actually be _reading_ your tripe.
Moving right along, it is also gaming industry that hinders Linux growth. The popular games like The Sims, Battlefield, Total Wars, Doom, and Madden 2k6 are not developed on Linux. WINE and Emulation software not the answer. It is only a temporary fix to the larger problem. Linux needs the game publishers and developers behind it.
I beg to differ.
There is no reason that Win32 and DirectX cannot be implemented on Linux at least as well as Windows, if not better.
I'd say Wine has already passed Windows 95, and 98. As it approaches its.9 release (non-alpha, finally! yeah!), its rapidly closing upon 2000/NT. Native theming is coming, too, which will make a huge visual difference, and Codeweavers has licensed truetype bytecode interpreting from Apple, so soon, Windows apps will start looking really slick on Linux. Codeweavers is starting to believe they can support the vast majority of windows apps (read _at least_ 95%) within two versions; and I've never known them to over-hype a product.
Transgaming has implemented DirectX on Wine (Cedega), and is developing rapidly. Any app without pixel shaders or vertex shaders performs substantially faster on Linux than in Windows. And their pixel shader implementation is catching up very quickly; I've seen an average 5% performance boost per released version, and they've been on a monthly release cycle.
The flip side of the coin is that when your app works well in either Crossover Office or Transgaming's Cedega, is becomes ridiculously easy to port. WineLib (CedegaLib) do 90% of the work automatically; the rest you can contract to Codeweavers of Transgaming for not much money at all (in the 4 figure range, easily within reach of most development houses, especially since it gives them an extra 'checkbox' on the package).
Use the venerable Loki installer, or a much better Autopackage, or even better, klik://, and you app becomes a double-click to install affair on linux.
You hope that you are lucky enough to have a Fry's Electronics, or a Microcenter in your area.
If not, you shop at local computing stores, where linux is 'cool'. Of course, those places are usually twice the price.
Either that, or you do your homework before you go to BestBuy, and when you tell them you run Linux you can enjoy the silence of being left alone by all the undertrained sales people.
I do not understand why ndiswrapper doesn't have a pretty gui to go with it.
Someone should write one; not like it has to be tough or anything.
'Click Install' 'Select WinXP Driver Directory for your Wireless Card' 'Installing' Either 'Install works!' or 'Wrong Driver for installed Wireless Card' or 'Driver is not compatible with this version of ndiswrapper, click to submit a bugreport'
If your company makes an even moderately popular piece of hardware, all you have to do for great Linux drivers is release documentation and information regarding the hardware interfaces.
If there are license restrictions regarding some of this stuff, keep it secret.
Honestly; if their competitors want to find out their product secrets, they'll reverse engineer them. The amount of money required to hire Chinese, Indian, or Pakistan developers (even highly qualified ones) to figure out what makes your 802.11g chipset tick is insignificant compared to the budgets of some of these companies. The only reason they don't release this kind of stuff is short-sightedness.
Either that, or MS really is behind the scenes, pushing to keep it all locked down.
1. Don't use Fedora. It's not a 'working-out-of-the-box' distribution. Use SuSE. All your updates are automagic, and stuff like 'Quake run with sound in less than an hour' archaic.
I can't believe anyone still goes through that kind of hell. There's a reason that SuSE doesn't update KDE between versions, and its to avoid that kind of inter-version breakage you experience. The full upgrade of the next SuSE revision incldues the next KDE, and it'll upgrade smoothly, too, assuming you have not tried to self-upgrade KDE in the middle.
2. Less expensive Windows Desktops: The article author is talking about preloaded linux machines. At Dell, or HP, a preloaded Linux machine costs more than a machine with exactly the same specs preloaded with Windows. Or, they'll both cost the same, and the Windows machine will come with a free monitor.
That's unreasonable, given that Dell doesn't have to pay anything to license Linux. On the other hand, what it does mean is that your MS-free system includes an MS-tax anyways.
You have to understand, from Joe Q. Public, or Mike A. Purchaser, when they want a system, they want it preloaded. Period. Preloaded Windows systems from the same vendor as exactly the same configured preloaded Linux systems are cheaper, therefore, Windows=cheaper.
Not that I agree with the viewpoint, but that's what he is refering too.
Slashdot Mirror
Download SuSE 10.0, the 'evaluation' edition, from Novell's site.
There are no limitations on the evaluation edition except that some generally unused packages do not come with it.
Open up the first disk, and open up the admin/install guide PDF, and the user guide PDF.
The SuSE documentation is phenomenal. Seriously. Everything you could possibly want to know (as a beginning to medium knowledge user) is there.
If you can afford it, I'd recommend buying it. It's only $30-$40 at your local store, and the books that come with it are really great.
http://www.undeadly.org/cgi?action=article&sid=200 51024113247
BTW: When he said, "just do it", he's not talking about informing management; he's talking about informing/surveying USERS. He's meaning, "Don't bother trying to convince users, instead, just tell them the procedures have changed, and this is 'The New Way' (TM) to do things. They'll do it, find it better/faster, than thank you"
Shamelessly stolen, so don't mod me up.
Mark T. Uemura (IP 221.249.159.51) (mark.uemura@gmail.com) on Tue Oct 25 14:18:17 2005 (GMT)
It's unfortunate that reporters such as this guy would sensationalize
a talk by carefully crafting his story from bits and pieces mostly
taken out of context. So, in all fairness to my firm and to those who
were not present, I feel compelled to set the story straight.
First off, the story is not an interview even though it may come across
as such. The title is rather sensational but I certainly wasn't
desperate. There were problems and they were fixed and our team was
just very resourceful in doing so.
Gedda writes:
> IT managers who want to deploy an open source solution but are worried
> about company politics should go ahead and do it without asking,
> according to PricewaterhouseCoopers (PWC) Japan IT manager Mark Uemura.
No, this is taken out of context. What I said was that we had very big
and important changes that we needed to make in order to restore network
and application stability. My reference to just going ahead and doing it
referred to making the necessary changes behind the scenes. It wasn't
about company politics and it wasn't about migrating services from Windows
to OpenBSD. My experience was that we did ourselves a disfavour by trying
to inform and explain to users and management the technical reasons for
the changes that needed to be made. In fact, all of the pushback had
nothing to do with OpenBSD. We needed to migrate from an old Domain
Controller with a corrupt Active Directory to a new one. We also
introduced the concept of working on Application Servers in Terminal
Services to take advantage of server power for resource intensive
applications that ran very slowly on users' PCs. So, the push back was
related to things like "you'll have to login to this new Domain rather
than the old one from tomorrow onwards." or getting users to change the
way they work and use applications running on a Terminal Servers for speed.
In the end, when all was sad and done, users and management realized the
difference that we had made; no more downtime or data loss. Furthermore,
they've never had everything running so smoothly and as efficiently for
as long as they could remember. Their IT problems went away as a result
of our efforts and the decisions that we made.
In fact, all of the migrations to OpenBSD were either behind the scenes
where the users were oblivious to the changes. Well, almost oblivious.
Often times we would get "Hey, the Internet is really fast today, cool!"
or "Man, can you guys like spill some coffee in the server room or
something? We're not used to this much uptime. It means we can't go
home early anymore!"
In those cases where users did have to interact with OpenBSD, it was
always well received and positive such as moving off of a very slow VPN
for remote access on to a quicker and more user friendly alternative
such as port forwarding applications through OpenSSH.
> Faced with an unreliable network, Uemura went ahead and migrated systems
> from Windows to OpenBSD on the premise that management would trust his
> judgement.
Once again, migrating services to OpenBSD was not an issue. So long as
we did not compromise security in doing so. Generally, we did so to
improve security and that's what OpenBSD is famous for and yet ther
And I'm a complete idiot.
/me should check fuckinggoogleit.com
WWN covers this very topic:
http://www.winehq.com/site/?issue=199
How to compile 32-bit wine on a 64-bit system, specifically for SuSE!
I'm guessing Wine will follow the Mozilla path.
How long did it take Mozilla to get to 1.0? How long did it spend in alpha, then beta?
Beta means that the project is starting to look like a finished product, or, at least the developers have figured out the basic 'specs' for the finished product. Don't knock it; OpenSource projects generally have a pretty high quality 1.0, while many companies (MS *ahem*, AOL *ahem*) release CRAP for version 1.0
Compile? I have NO idea how to compile Wine on a 64-bit system. I cannot get it to work.
;-)
I've spent a LONG time trying to do so, and I've not been able to find anyone to point me in the right direction.
That being said, the 32-bit binaries work brilliantly on any 'modern' 64-bit linux. I suspect this doesn't include debian
I only really run SuSE, but the latest 32-bit Wine installs without a hichup, and everything works exactly as it would under a 32-bit install (I'm using a 64-bit kernel).
I'm not sure how other distributions do it, but SuSE installs the 64-bit libraries alongside the 32-bit ones, points 64-bit apps at lib64, and everything 32-bit seems to work perfectly. I've heard you can acheive the same effect using a chroot 32-bit install on a 64-bit debian, but I've never tried.
Yes, and yes.
.) in DX9WINE, which has been integrated into the Wine CVS tree.
Commercial?
Go to www.transgaming.com
World of Warcraft, Half-Life 2, City of Heroes, and many other games work properly under Cedega, Transgaming's version of Rewine (the BSD wine).
Wine?
Yes.
Wine main has quite a few DirectX features properly implemented, and Oliver Steiver (sp?) is implementing many Direct3D 9 features (like pixel shaders, etc. .
So yes, its been done, and yes, a lot of stuff works. Cedega gives me my gaming fix in Linux. I've currently got Eve Online, Secondlife, Half Life 2, Age of Wonders, World of Warcraft, and some other titles I don't play much installed. Works great.
Well, the problem with Win32 is that much of it is unknown territory :) It's difficult to implement something that is completely undocumented while being quite as huge as Win32.
.). In order to keep it working for that stuff, it makes sense to stop generating new implementations, and work out as many of the bugs as possible. Thus, nothing to revolutionary will be accepted into the tree between now (beta) and 1.0 (release). Patches between now and then will focus on making sure existing functionality works properly. Once 1.0 happens, new features can be implemented on an as-needed basis.
.'
Also, certain things are unimplementable, but also don't work in modern Windows anyways. VxDs, for example, often break in XP. Multi-user support doesn't make much sense, given that each Wine 'install' (/home//.wine/) is single user.
The amount of implemented 'stuff', however, is quite telling, especially considering that the latest and greatest Office suite (2003) runs on Wine now.
Also, notice the update date on the status page? August 16, 2005 . . . . I know that the Direct3D stuff has come a LONG way; the status page lists d3d8 as 10% done, while in reality, d3d9 is almost there. Especially true with the gaming 'stuff', but also for general cases, support is app driven. 'X' app breaks because 'Y' function isn't implemented yet. So someone picks it up. Combined with a few general architechtural changes (like the Installshield stuff), you get 90% app support. Remaining work is completed on an as-needed basis. The flip-side of this process is that you get up to speed on new stuff coming down the MS pipeline.
To your second question. "Beta". What does it mean?
Beta means 'feature freeze'. Wine, as a Win32 API implementation for Unix, is useful now. You can run IE, Office 2003, Google Earth, Picasa, Photoshop, and a boatload of other popular apps. (Quickbooks, etc. .
So far, in 'alpha', the Wine developers were not afraid to break major parts of the API. Often, a snapshot would be almost unusable, or break dozens of applications. This is necessary when certain sections of the code had to be ripped out and reimplemented.
Now that Wine is getting more and more functional/useful, this development methdology will have to change. With release, it'll be safe for Linux distributions to list support for certain Windows applications using the free implementation of Wine. That'll be quite a coup if you think about it. 'Includes Wine 1.0, support for Office 2003, Internet Explorer 6, Adobe Photoshop CS, etc, etc. .
I imagine the Wine 1.0 tree will continue to receive bug/security updates along side newer versions.
The end vision of the Wine project is not emulation layer. The end vision of the Wine project is a fully functional UNIX app API, alongside things like QT/KDE, or GTK2/Gnome. Moving out of the haphazard alpha state of the project is a necessary step in its maturity.
Once themeing is supported, you can start with a static theme, like:
:)
XP Bluecurve
http://www.deviantart.com/deviation/4279121/
or
XP Plastik
http://www.deviantart.com/deviation/8066296/
I'm sure GTK and QT engines will come. Question is, if they build a GTK engine, will it work with the QT->GTK theme?
They don't need to do this.
All they need to do is create an Autopackage, or, better yet, and Autopackage and a klik:// image.
Autopackage kicks ass.
http://autopackage.org/
We already have _several_ package management schemes that work across distributions AND desktop environments.
./configure, make, make install time has passed.
Autopackage is extremely user friendly, for example.
Apt works most everywhere (deb, rpm, tgz distributions)
SMART takes that integration work to another level (http://labix.org/smart)
klik:// is super-duper friendly for end users, and even with the K its being taken to gnome.
We don't need new technology. We need the existing technology to be made more wide ranging.
SMART builds on RPM/DEB/APT/TGZ systems, abstracting package management at a high-level. You can still use the 'older' tools, however. Think server.
klik:// is far easier installs for the end-user, and the klik:// architecture is mostly distribution agnostic.
Autopackage is very intelligent about putting whatever is needed whereever its needed, and fairly distribution agnostic.
The job of the LSB should be to push these standards, and make documentation avaliable so that these tools can work everywhere. Also, to make it _far_ easier to build packages that autoconfigure themselves for any distribution, and correctly setup dependencies for the appropriate package manager.
The best thing about building newer package management tools on older framework is that you don't have to change anything; you can keep doing what you are doing, or you can move on to the 'smarter' tools. If you build a flexible enough API, it doesn't have to be targetted at _any_ framework. You build tools into the desktop environment to support whatever package management scheme you could possibly desire, or you just rely upon integration with older standards to remain sane. In fact, proper standardization on flexible package management could actually encourage MORE variety in Linux desktop environments. If there's a standard way to handle installed apps and dependancies you don't have to do as much work in your desktop environment.
Flexibility thrives in an environment of sophisticated, easy to use tools. Look at all the work distribution creators have had to do to get their gnome and KDE to 'integrate'. If both can suddenly hook into a distribution agnostic app management system, you can provide more choice in environment at a far lower integration cost.
Regarding desktop/server distinction; that's simple. RPM/APT whatever isn't going away. The newer 'layers' are RPM/APT aware. Server/Desktop common software is managed at this level, using RPM/APT. Other utilities build on top of these; they transparently manipulate RPM/APT, using pretty GUI one-click install tricks, this, that, and the other. The only 'separation' is increasing layers of complexity.
Really, the only thing that will go away is unmanaged source-installs, because they really don't make any sense. It's very difficult to manage source-installs in a package managed world; there are a few utilies that will 'wrap' sourceinstalls into an RPM or a DEB, but you still have to do dependencies and the like by hand.
RPM isn't _that_ bad, however, its not all that great, either.
No conditional dependencies, for one. Difficulty in building multiplatform RPMs, for two.
There are alternative software distribution systems that do this better. Like autopackage, or dare I say klik://
The best of both worlds is an alternative package system that customizes for your system, and wraps the necessary-bits-to-be-installed in an RPM at the last minute. That way, you can install using, say, Autopackage, or plain source, and remove the RPM when you don't need it anymore.
I think its Kdesourceinstall does that, I can't remember the proper name of the package right now.
klik://, however, will make all these issues go away if it catches on. klik:// style packaging is the future of software distribution.
Well, if its a small company, writing an uncomplicated driver, than the opensourcing the "spec" means that the guy sitting next to the guy designing the board simple puts his work online somewhere :)
SiS started to do that kind of thing, but they were so hopelessly behind in their release schedule that it was just silly.
Well, for the enterprise, there is no problem buying Crossover Office, or even Transgaming (not that you'd need gaming in the enterprise).
For the home user, Crossover Office is available for _free_, since the roll all of their improvements into Wine CVS before they integrate them into Crossover Office. Pro support costs money; again, you have to pay for that with windows. Plus, winehq.org free support is pretty awesome.
Transgaming costs $5 a month, with a three month minimum. You can also download it for free; however, given that their support is _really_ good, I'd think its worth it. Some distributions have taken to licensing both Transgaming's Cedega & Crossover Office, and including them in; I suspect thats the future.
Either way, even if you buy both ($35 + $15), you are still below the OEM cost of a Windows install; and you aren't even including the cost of spyware & viruses, either in removal software or lost time.
How many leaders of tech companies are truly tech geeks?
Actually, many.
A majority of non-fortune 500 companies that have substantial growth are run by geeks. Go look at finance.yahoo.com
A fair number of fortune 500 companies that have substantial growth are also run by geeks, too.
Don't just consider 'companies'. Look at 'growing' companies.
Google. Apple. Redhat. Even if some of these leaders have become less 'geeky' over time, its just a combination of leadership plus geek. Not pure-mba goodness.
One could even say this about Michael Dell, an excellent example of a 'leader' type.
As a layman's engineer, with many 'true' engineers as co-workers, what you are saying couldn't be further from the truth.
Apple's designs are generally over-engineered (The Cube was not). Power supplies are more than 'sufficient', heat issues and the like are very well considered.
Not so in Dell designs. Desktops, or laptops. I've owned several, my company _used_ to purchase them, and they are of *crap* quality.
The 3 inspiron 8200s we owned, in particular, literally fell apart. Screws were loose, and the systems began to rattle. I've _never_ seen this on a Powerbook.
I say this as a person who builds his own systems, and runs Linux (SuSE-10.0) everwhere I can. Mac OS X is quite a nice OS, and its Unix guts are pleasantly arranged. I *do* prefer Linux; however, there is a HUGE middle ground between the 'tech savvy' and the 'artstic technophobe', and OS X fills that marketspace (i.e., the MAJORITY) nicely.
A well-known, convicted monopolist releases buggy, unreliable software.
A well-known, convicted monopolist then seeks to sell a 'protection' service to keep said buggy, unreliable software working, and much of the media sees this as a boon.
A well-known, convicted monopolist releases 'leaks' of a 'Next-Generation' operating system, whose primary features are a new GUI, whose primary characteristics change substantially between each set of 'leaks'. Yet every tech journalist and their mother OOHs and AAHs these 'leaks'.
A well-known, convicted monopolist releases 'interviews' with the characteristics of a press release, discussing how growing markets represent a grand opportunity for the company. This same company, whose 'Next-Generation' operating system is extremely late and feature triaged to the point of unrecognition, is portrayed as setting itself up for a 'win' in that it will 'beat' current market leaders by providing features they've provided for years.
Yep; tech journalists are biased. Mr. Dvorak, please keep telling me about how Apple is doomed; it gives me a great way to discredit you with any PHBs who might actually be _reading_ your tripe.
Moving right along, it is also gaming industry that hinders Linux growth. The popular games like The Sims, Battlefield, Total Wars, Doom, and Madden 2k6 are not developed on Linux. WINE and Emulation software not the answer. It is only a temporary fix to the larger problem. Linux needs the game publishers and developers behind it.
.9 release (non-alpha, finally! yeah!), its rapidly closing upon 2000/NT. Native theming is coming, too, which will make a huge visual difference, and Codeweavers has licensed truetype bytecode interpreting from Apple, so soon, Windows apps will start looking really slick on Linux. Codeweavers is starting to believe they can support the vast majority of windows apps (read _at least_ 95%) within two versions; and I've never known them to over-hype a product.
I beg to differ.
There is no reason that Win32 and DirectX cannot be implemented on Linux at least as well as Windows, if not better.
I'd say Wine has already passed Windows 95, and 98. As it approaches its
Transgaming has implemented DirectX on Wine (Cedega), and is developing rapidly. Any app without pixel shaders or vertex shaders performs substantially faster on Linux than in Windows. And their pixel shader implementation is catching up very quickly; I've seen an average 5% performance boost per released version, and they've been on a monthly release cycle.
The flip side of the coin is that when your app works well in either Crossover Office or Transgaming's Cedega, is becomes ridiculously easy to port. WineLib (CedegaLib) do 90% of the work automatically; the rest you can contract to Codeweavers of Transgaming for not much money at all (in the 4 figure range, easily within reach of most development houses, especially since it gives them an extra 'checkbox' on the package).
Use the venerable Loki installer, or a much better Autopackage, or even better, klik://, and you app becomes a double-click to install affair on linux.
See the migration pattern?
Bwahahaha....
Saddam's Iraq was a U.N. member, while Taiwan wasn't (and isn't)
Say that part again, about how U.N. membership is available to all peace loving states?
They've already tried to go after him in Norway, using both U.S. and Norweigan law.
:(
AFAIK, hes got a fair amount of experience with the legal system already
SuSE Professional 10.0 costs ~$50.00, and you get support from Novell. I think you get 1 year.
You can buy more years of support if you want, too.
You don't shop at BestBuy or Circuit City.
You hope that you are lucky enough to have a Fry's Electronics, or a Microcenter in your area.
If not, you shop at local computing stores, where linux is 'cool'. Of course, those places are usually twice the price.
Either that, or you do your homework before you go to BestBuy, and when you tell them you run Linux you can enjoy the silence of being left alone by all the undertrained sales people.
This SuSE howto requires minimal computing knowledge:. html
http://www.novell.com/coolsolutions/feature/15484
I agree that it is still too complex for John Q. Public, but its pretty close.
Good point.
I do not understand why ndiswrapper doesn't have a pretty gui to go with it.
Someone should write one; not like it has to be tough or anything.
'Click Install'
'Select WinXP Driver Directory for your Wireless Card'
'Installing'
Either
'Install works!'
or
'Wrong Driver for installed Wireless Card'
or
'Driver is not compatible with this version of ndiswrapper, click to submit a bugreport'
Wouldn't be much work, perhaps I should try....
Agreed.
If your company makes an even moderately popular piece of hardware, all you have to do for great Linux drivers is release documentation and information regarding the hardware interfaces.
If there are license restrictions regarding some of this stuff, keep it secret.
Honestly; if their competitors want to find out their product secrets, they'll reverse engineer them. The amount of money required to hire Chinese, Indian, or Pakistan developers (even highly qualified ones) to figure out what makes your 802.11g chipset tick is insignificant compared to the budgets of some of these companies. The only reason they don't release this kind of stuff is short-sightedness.
Either that, or MS really is behind the scenes, pushing to keep it all locked down.
1. Don't use Fedora. It's not a 'working-out-of-the-box' distribution. Use SuSE. All your updates are automagic, and stuff like 'Quake run with sound in less than an hour' archaic.
I can't believe anyone still goes through that kind of hell. There's a reason that SuSE doesn't update KDE between versions, and its to avoid that kind of inter-version breakage you experience. The full upgrade of the next SuSE revision incldues the next KDE, and it'll upgrade smoothly, too, assuming you have not tried to self-upgrade KDE in the middle.
2. Less expensive Windows Desktops: The article author is talking about preloaded linux machines. At Dell, or HP, a preloaded Linux machine costs more than a machine with exactly the same specs preloaded with Windows. Or, they'll both cost the same, and the Windows machine will come with a free monitor.
That's unreasonable, given that Dell doesn't have to pay anything to license Linux. On the other hand, what it does mean is that your MS-free system includes an MS-tax anyways.
You have to understand, from Joe Q. Public, or Mike A. Purchaser, when they want a system, they want it preloaded. Period. Preloaded Windows systems from the same vendor as exactly the same configured preloaded Linux systems are cheaper, therefore, Windows=cheaper.
Not that I agree with the viewpoint, but that's what he is refering too.