Instead the OS must be modified to support it. If you look at the Xen homepage you'll see more details.
Whilst this doesn't diminish the usefulness of the project it does mean you cannot host an XP installation - like you can with Qemu , or the commerical software VMWare.
I have used Qemu extensively in the past to host installations of Windows upon my Debian machine - whilst it is not as fast as Xen promises to be it is the best around at the moment (short of spending cash!)
I wrote some software which was moderately useful and semi-popular.
When it came to be time to look for a job I asked around locally. One guy recognised my name after having used the software at his home.
That was enough to land me an interview. Of course once I got that I was on my own.
I suspect this happens a fair bit, you won't get a job unless you wrote something insanely popular but it might help you get an interview.
(Although writing something yourself, even with other people to help, from scratch is much more useful in terms of being recognised than adding a ten line patch to the Linux kernel, samba, or Apache).
Here in Edinburgh I found the same thing. Instead I would walk to the large Tesco store every other Saturday and buy lots of shopping.
When you buy a lot you can then get a Taxi home - cost to me about a fiver.
Nowadays instead I just order online. Less hassle than dealing with a supermarket on a weekend with families and children and the delivery charge I can rationalise away as the fare I would have previously spent upon the taxi ride home.
Of course I still have to remember to buy milk + bread from the supermarket close to my work on the way home, but otherwise I'm good.
I've got a couple of SCO boxes, running old, but essential, console applications written in Microfocus Cobol.
For the past few months I've been looking at replacing them with Linux machines - there's no way I'd be looking at upgrading the SCO OS.
Whilst SCO OpenServer 5.0 isn't amazing it has been reasonably stable. The tools available are all outdated, and reasonably cryptic. Augmenting them with the addition of lots of GNU stuff from Skunkworks makes using the machines bearable - but many things just aren't available. (eg. Working legato backup clients.)
The biggest problem with SCO installations I have, in remote offices, is the lack of hardware support. Many many common, or cheap, pieces of hardware just aren't supported.
Since Microfocus Cobol runtimes exist, or used to exist, for Linux I'm thinking the pragmatic thing to do is just migrate. It won't be free, but it will ease support in the future - both in terms of hardware support and general reliability.
Sometimes I've come into work to find a SCO kernel panic with no obvious explaination. They also degrade significantly under load, despite best efforts at tuning. (However this could be the hardware, or the application itself - hard to tell).
I find it hard to believe the SCO will attract significant new customers - perhaps some customers will upgrade to keep their vertical applications, or sourceless code, running. But they've managed to either alienate or upset their clueful client-base.
SCO doesn't really have a future right now, as far as I'm concerned.
Seriously why would you have UFO files connected to a network (assuming you would have any digital data in the first place rather than just paper and ink) unless as misinformation?
Teams are more divided up according to specialty than a specific title, which is why the end result is less than innovative or interesting.
Reading the article it seemed like this was the case, and that communication with sales, marketting, programming teams was a key skill.
To me that explains a lot of the lack of creativity - by the time you've agreed compromises with each different team you've essentially designed a game by committee.
Whilst I know none of my work will ever really take off there's a lot of fun to be had, even now, from writing your own game from scratch.
OK so the graphics and the sounds won't be pixel perfect - but virtually every game from the 80s I played on the ZX Spectrum I know I could replicate, given enough time. And some of them could easily be extended with bigger maps, etc.
Yet the last time I flew in to the USA (second time ever) I consistently set off all the alarms I walked through - with my 13+ piercings.
Once or twice I got a pat-down, other times I just pointed to the visible piercings and said "more piercings". That was sufficient for me to walk through unmolested.
I find it hard to understand why I wasn't searched more carefully. Although the sheer backlog and slowdown of throughput at the boarding gates might have had something to do with it...
The big pro is since the licensing change almost all Linux vendors have moved to X.org.
That means there's more momentum behind it, and a lot of work will be happening on the new codebase - in a more open way.
Technically, right now, there are some changes between the two but nothing major unless you're using one of the cards for which the driver has been updated.
One complication to the upgrade not really covered here (I wrote that article) is the simultaneous C++ ABI transition Debian Unstable is going through.
This means that upgrading might cause you to loose a lot of packages like gdm, etc.
So if you try the upgrade and apt-get, or aptitude demand you remove lots of packages then the reason is the C++ ABI change - and if you simply wait a few days/weeks it should resolve itself.
At the time the article was posted things were less bad.
I think running on the server side would be a strange way to implement this.
Whilst it's certainly possible to open registries, and process lists, remotely if you have "Domain Administrator" privileges it seems much simpler to look at things locally.
The network overhead of scanning a filesystem across a network, and then pulling down the registry hives to scan through those would be crippling with multiple workstations to be scanned.
Pulling definitions from the network server, and having forced scanning on demand from a central location would be useful. but I'm not sure that implies the whole system should be run centrally; just some kind of admin console.
.. and thanks for the site recognition, it seems to be growing nicely:)
I've written about this before. Writing an anti-spyware program which scans the process list, the registry, etc is trivial.
The hard part is vetting the datafile(s) and keeping things up to date.
Whilst it could be done, as the AV program clamav manages it with only volunteers. I can't see the market for it.
The people that would be attracted to working on a program would probably prefer to support Linux platforms instead.
Even if they did start working on it, it would be hard to gain marketshare until it worked very well - so it needs a lot of effort initially from a few users to get the datafiles covering most of the common and difficult to remove parasites.
And companies with large, vulnerable, desktop installations presumably have the budget to either purchase a commerical spyware scanner, or the knowhow to use Spybot S&D.
I think that there are enough Debian admins that finding assistance isn't difficult.
What you appear to be saying is that nobody will switch to Debian/Linux because they don't know it - yet this isn't what is actually happening.
New users and admins are experimenting and switching constantly, and as their experience grows they'll be more happy with doing their jobs, adding new services etc.
A system administrator who isn't willing or capable of learning to use something new isn't one worth employing in my eyes. God knows there's enough variation between Unixs like HP-UX, Solaris, etc, that minor changes to Debian/Linux shouldn't be completely new territory.
Perhaps you have a point if you've got an Admin who only knows Windows, but even so the same concepts occur frequently; testing things, stopping and starting services, installing software, and learning how to use new packages.
This might even be a good time to plug my debian administration website which attempts to explain how to do common tasks and the like for people who are new to Debian.
Slashdot Mirror
No Xen cannot virtualize/host any OS.
Instead the OS must be modified to support it. If you look at the Xen homepage you'll see more details.
Whilst this doesn't diminish the usefulness of the project it does mean you cannot host an XP installation - like you can with Qemu , or the commerical software VMWare.
I have used Qemu extensively in the past to host installations of Windows upon my Debian machine - whilst it is not as fast as Xen promises to be it is the best around at the moment (short of spending cash!)
I wrote some software which was moderately useful and semi-popular.
When it came to be time to look for a job I asked around locally. One guy recognised my name after having used the software at his home.
That was enough to land me an interview. Of course once I got that I was on my own.
I suspect this happens a fair bit, you won't get a job unless you wrote something insanely popular but it might help you get an interview.
(Although writing something yourself, even with other people to help, from scratch is much more useful in terms of being recognised than adding a ten line patch to the Linux kernel, samba, or Apache).
Here in Edinburgh I found the same thing. Instead I would walk to the large Tesco store every other Saturday and buy lots of shopping.
When you buy a lot you can then get a Taxi home - cost to me about a fiver.
Nowadays instead I just order online. Less hassle than dealing with a supermarket on a weekend with families and children and the delivery charge I can rationalise away as the fare I would have previously spent upon the taxi ride home.
Of course I still have to remember to buy milk + bread from the supermarket close to my work on the way home, but otherwise I'm good.
And todays new poll has no comments allowed - just like what happened to the previous one for the first few days.
Something must be broken/breaking ..
Doesn't compare I'm afraid - the Microfocus stuff has it's own proprietry screen/form system.
Many shops running SCO will be stuck with old binaries handed down from companies who have gone out of business.
Without source the best you can do is use emulation, porting is likely out of the question for many companies.
I already have Linux, Windows, SCO, and Solaris machines to look after.
Whilst I like *BSD introducing yet-another operating system into the server room mix is just asking for trouble.
(It'd make hiring a replacement harder, and increase complexity overall.)
I'd rather simplify the current situation by removing the SCO bringing the distinct operating system count down to Linux, Solaris and Windows.
I've got a couple of SCO boxes, running old, but essential, console applications written in Microfocus Cobol.
For the past few months I've been looking at replacing them with Linux machines - there's no way I'd be looking at upgrading the SCO OS.
Whilst SCO OpenServer 5.0 isn't amazing it has been reasonably stable. The tools available are all outdated, and reasonably cryptic. Augmenting them with the addition of lots of GNU stuff from Skunkworks makes using the machines bearable - but many things just aren't available. (eg. Working legato backup clients.)
The biggest problem with SCO installations I have, in remote offices, is the lack of hardware support. Many many common, or cheap, pieces of hardware just aren't supported.
Since Microfocus Cobol runtimes exist, or used to exist, for Linux I'm thinking the pragmatic thing to do is just migrate. It won't be free, but it will ease support in the future - both in terms of hardware support and general reliability.
Sometimes I've come into work to find a SCO kernel panic with no obvious explaination. They also degrade significantly under load, despite best efforts at tuning. (However this could be the hardware, or the application itself - hard to tell).
I find it hard to believe the SCO will attract significant new customers - perhaps some customers will upgrade to keep their vertical applications, or sourceless code, running. But they've managed to either alienate or upset their clueful client-base.
SCO doesn't really have a future right now, as far as I'm concerned.
Actually the perl source code is full of fun comments like the Tolkien quote The road goes ever on..
It helps lighten the mood when reading it... and the other comments are useful and helpful too.
Or the 30Mb trailer direct.
Mabye that's what they want you to think ...
Reading the article it seemed like this was the case, and that communication with sales, marketting, programming teams was a key skill.
To me that explains a lot of the lack of creativity - by the time you've agreed compromises with each different team you've essentially designed a game by committee.
Whilst I know none of my work will ever really take off there's a lot of fun to be had, even now, from writing your own game from scratch.
OK so the graphics and the sounds won't be pixel perfect - but virtually every game from the 80s I played on the ZX Spectrum I know I could replicate, given enough time. And some of them could easily be extended with bigger maps, etc.
Maybe bayesian filtering of upcoming shows based upon their descriptions?
So even if the program name/time isn't like anything you've liked before if the description matches something you've liked it would be recommended?
Yet the last time I flew in to the USA (second time ever) I consistently set off all the alarms I walked through - with my 13+ piercings.
Once or twice I got a pat-down, other times I just pointed to the visible piercings and said "more piercings". That was sufficient for me to walk through unmolested.
I find it hard to understand why I wasn't searched more carefully. Although the sheer backlog and slowdown of throughput at the boarding gates might have had something to do with it ...
It seems like there's already at least one very lonely Whale out there - maybe that could be friends with it?
Isn't this what the book / online book Creating applications with Mozilla was supposed to help with?
Sure it's about applications rather than interfacing with the core of the browser, but it covers the concepts of XUL, packaging, etc.
Stable has only been released a month and a half ago - so it's clearly not out of date too much.
Sure if the release of the next Debian Stable, codenamed etch doesn't happen for another two years then it will be outdated. But right now it's not.
The big pro is since the licensing change almost all Linux vendors have moved to X.org.
That means there's more momentum behind it, and a lot of work will be happening on the new codebase - in a more open way.
Technically, right now, there are some changes between the two but nothing major unless you're using one of the cards for which the driver has been updated.
One complication to the upgrade not really covered here (I wrote that article) is the simultaneous C++ ABI transition Debian Unstable is going through.
This means that upgrading might cause you to loose a lot of packages like gdm, etc.
So if you try the upgrade and apt-get, or aptitude demand you remove lots of packages then the reason is the C++ ABI change - and if you simply wait a few days/weeks it should resolve itself.
At the time the article was posted things were less bad.
I think running on the server side would be a strange way to implement this.
Whilst it's certainly possible to open registries, and process lists, remotely if you have "Domain Administrator" privileges it seems much simpler to look at things locally.
The network overhead of scanning a filesystem across a network, and then pulling down the registry hives to scan through those would be crippling with multiple workstations to be scanned.
Pulling definitions from the network server, and having forced scanning on demand from a central location would be useful. but I'm not sure that implies the whole system should be run centrally; just some kind of admin console.
.. and thanks for the site recognition, it seems to be growing nicely :)
Well you can do what Slashdot itself does - which is deny users of Tor from posting comments.
A sad reflection on the malicious actions of a few outweighing the positive aspects of privacy and encryption on the many.
I've written about this before. Writing an anti-spyware program which scans the process list, the registry, etc is trivial.
The hard part is vetting the datafile(s) and keeping things up to date.
Whilst it could be done, as the AV program clamav manages it with only volunteers. I can't see the market for it.
The people that would be attracted to working on a program would probably prefer to support Linux platforms instead.
Even if they did start working on it, it would be hard to gain marketshare until it worked very well - so it needs a lot of effort initially from a few users to get the datafiles covering most of the common and difficult to remove parasites.
And companies with large, vulnerable, desktop installations presumably have the budget to either purchase a commerical spyware scanner, or the knowhow to use Spybot S&D.
I think that there are enough Debian admins that finding assistance isn't difficult.
What you appear to be saying is that nobody will switch to Debian/Linux because they don't know it - yet this isn't what is actually happening.
New users and admins are experimenting and switching constantly, and as their experience grows they'll be more happy with doing their jobs, adding new services etc.
A system administrator who isn't willing or capable of learning to use something new isn't one worth employing in my eyes. God knows there's enough variation between Unixs like HP-UX, Solaris, etc, that minor changes to Debian/Linux shouldn't be completely new territory.
Perhaps you have a point if you've got an Admin who only knows Windows, but even so the same concepts occur frequently; testing things, stopping and starting services, installing software, and learning how to use new packages.
This might even be a good time to plug my debian administration website which attempts to explain how to do common tasks and the like for people who are new to Debian.
The combination of open sores and a finger scanner doesn't sound too hygenic to me.
I guess if I had a fingerprint scanner I'd want to clean it regularly if people are going to start trying to use it randomly...
It could well have been the recently revealed XML-RPC exploit which Drupal appears to have been vulnerable to.
Debian released an updated Drupal security package today. I'm sure other distributions have also done so, or are about to.