I wonder if there's a custom nokia class for this "explosion" technology for java. This could really tickle a game up a bit - you know, add to the experience. "You lose the level - you lose your hands;-)"
From my experience of Webmin, it causes more problems than it solves in all but the simplest of administration tasks. Certainly it's capable of completely screwing up a server with any previous customised scripts.
I have installed in in cases where a server would be left to the charge of a novice, but I disable many of the worst modules. EG, Samba, Sendmail, MySQL, printer admin, named admin etc. The reason being it's far better to use the dedicated web interfaces for these, or in the case of Sendmail, leave it to an expert/someone competent.
I can see why a complete novice with a new box might find it useful, but for any remotely complex setup, it's woefully inadequate...
The point of the roadshow is to tell people who ARE NOT THERE what they missed, and to make SCO appear to be a big, vibrant operation that requires road shows.
Damn, if only this crowd of thousands of technology geeks could muster up a single video camera between them... No, I suppose that's just crazy talk....
Yes, only in the USA would people do this. That's why I never receive spam from Asia, Africa, or Europe. Your knee-jerk anti-americanism is as bad as the spammers' greed, I'm afraid.
Uhu, funnily enough all the spam (I see) coming from Asia tends to be advertising American companies. The only spam I get from Europe is Russian Pr0n, with some scammers posting from Africa. I'd say the overwhelming majority is from US sources or advertising US "companies" (>95%).
Re:Does this ver. solve the WinXP security "featur
on
Samba 3.0.0 Released
·
· Score: 2, Insightful
I call bullshit here. I regularly set up Linux Samba servers (file and print) that work fine with Win98, NT, 2K and XP machines. Both standalone and as domain members. I've used both the normal smb password file and LDAP passwords for authentication, and it all works faultlessly.
In fact I'm sitting at an XP machine right now that's mounting from 3 different Samba servers...
Unless I'm missing something, this novel idea is complete garbage. Yes, sure you can disassemble the machine code, produce some C code from that and then recompile for a new target CPU but it's not going to work for the vast majority of applications.
The reason: hardware.
Even your average 80's arcade machine relies upon custom hardware for virtually everything. The main program spends most of its time simply adjusting registers to control sprites etc, and reading from hardware to detect collisions and so on. This new code you've generated for a new CPU will still expect the same supporting hardware...
Of course you're correct, IF we assume transportation, storage and marketing all cost zero. AND we assume no units will ever break-down, nobody will ever need support, and the product never requires any kind of bugfix (software or hardware) in its entire lifetime... So, if all that is correct, then so are you...
I agree that it won't do well, but for different reasons:
(1) All games consoles, including handhelds are sold at a loss, with the expectation that the licenced software sales will more than recoup the hardware costs. Nokia are not doing this - they are charging full price for the hardware, and then leaving the developers free to charge full price for the software. Nintendo and co can't lose so long as they produce great games, or profit from the 3rd party developers, but Nokia, as a hardware-only company don't have this revenue channel.
(2) The hardware in that phone is virtually identical to the 7650 and 3650 Nokia phones, which are considerably cheaper. These already have very large software catalogues, and the userbase to encourage developers to write new games for them. Producing cartridges for a single unproven platform is VERY risky for a company, so any games for the NGage will likely be slightly enhanced (if at all) versions of the games for the other 60 series phones.
It refuses to use my good sound card and instead uses the on-board card. Etc. etc. etc.
Just a quick idea: Why not disable the onboard sound chip in the BIOS? Or maybe just build the kernel without the driver for the motherboard chipset (or delete/disable the existing driver if it's a module)?
Re:SCO's MIcrosoft connection?
on
SCO Roundup
·
· Score: 1
I've been following the news at Groklaw regarding SCO for some time now, and have submitted stories to/. several times (all rejected of course). The evidence has been piling up - shady companies pumping money into SCO despite the overwhelming bad news, directors appearing to be blatantly pumping stock prices. Third parties spewing FUD like no tomorrow. Personally though, I'm convinced Sun is playing a big part in working the SCO sock-puppet, not just MS...
"It's like a house that hasn't been maintained in a few years," McBride said. "We're going to come back and spruce the place up."
For some reason I have this image of some dungaree-wearing, straw-chewing hick pulling up beside a Porsche in his rattling, dented, rusting 1950's pickup, belching black smoke and yelling over "Hey boah, wan't me ter help yuh fix that ther car o' yors up? Ah'll only charge yuh 2 billion bucks! Yeehaw!"
DHTML is a Microsoft creation and is not part of any recognized standard.
How on Earth was this modded up as informative? Sure, it informs us that rossz is totally ignorant about this subject, but DHTML is definitely NOT a "Microsoft creation". Netscape 4 had DHTML capabilities well before the first capable MS browser (IE4) appeared.
DHTML stands for "Dynamic HTML". It's the result of manipulating the browser DOM using a scripting language (virtually always Javascript).
[Microsoft security flaws comparable to car maker design flaws] A more apt analogy would be Ford making a car with a radio so defective that the car would explode if it received a signal of a certain frequency.
Your analogy is flawed. Ford wouldn't continue to sell cars from the dealer forecourts with the "exploding radios". You think PC World, or any other store (online or otherwise) send all the unpatched copied back to Redmond after an alert?
There's that, and the fact that Microsoft's search engine is the default page when IE tries to visit a broken link/dead site. Many people I know use MS's search engine simply because it's the default, and they don't realise there are far better alternatives out there. These same people are usually very pleased when I set up Google as the start page in their browsers;-)
In my case, the vast majority are Excel files, which I explained above. However, it can also generate graphs and charts when required. These can be used standalone, or inserted into the spreadsheets.
Of course, it takes slightly longer to set up a new report this way (although a lot of the code is pretty reusable), but it pays off when you convert a report that's generated many times a day, or there are many reports to generate.
For more speed, I can often get away with CSV files for the output - reducing (in one case) a report from 45+ minutes to 17 seconds - sure, it's not quite as pretty, but it was much more current, and could be generated every 5 minutes instead of 5 times a day...
(As an aside, I tried both perl and php scripts for this, and perl is twice as fast even when running almost identical code - the DB query takes the same amount of time, but subsequent processing is much faster).
SpamProbe can be fooled by clever spammers who insert lots of common words in non-visible html.
Well it's not that clever, I've configured SA to mark obfuscated mail +20, so it's always caught immediately. The only people using this feeble trick are spammers, so there's no likelyhood of a false positive...
Actually I use the Open-Office spreadsheet quite a bit at work, and can't see any reason to change to be honest. Part of my job involves perl scripts that generate.xls spreadsheet reports at night for users to view the next day and my tests with OO render them exactly the same as the users see them with Excel.
BTW, the reason we switched to doing this was due to the old system; where Access was running on PCs, and generating reports was so damned slow! It may seem unbelievable, but changing from Access+MySQL (we replicate from our Oracle server for reports and other stuff) to Perl+MySQL on Linux resulted in a staggering increase in speed. Reports that were taking an hour are now completed in under 2 minutes! The method I use to convert from Access->perl is, firstly take the Pseudo-SQL Access generates, then customise it a bit for MySQL, then use the Spreadsheet::WriteExcel module for perl. It's great!
I've never used Access myself BTW, and don't really understand what the hell it's doing to use all the CPU cycles. We watched it's activity one day - it ran a query on the Linux box, which took 12 seconds (monitored it with "top"), it then pegged the Windows PC - a P4 2.4ghz - running Access at 100% load for a good 20 minutes generating a spreadsheet!! WTF?!
So, to anyone else suffering with slow Access reports, learn some perl;-)
I'll take your SCO OpenServer and raise you an HPUX 11 as shittiest unix. Luckily we also have Linux machines at work, so just nfs mount all of its directories (no_root_squash;-) so we don't have to use it's braindead tools most of the time... Having to rebuild the kernel after a memory upgrade?! WTF? The sooner we can get the two pieces of software on there (one of which is Oracle) moved to Linux the better... </Rant>
Slashdot Mirror
I wonder if there's a custom nokia class for this "explosion" technology for java. This could really tickle a game up a bit - you know, add to the experience. "You lose the level - you lose your hands ;-)"
From my experience of Webmin, it causes more problems than it solves in all but the simplest of administration tasks. Certainly it's capable of completely screwing up a server with any previous customised scripts.
I have installed in in cases where a server would be left to the charge of a novice, but I disable many of the worst modules. EG, Samba, Sendmail, MySQL, printer admin, named admin etc. The reason being it's far better to use the dedicated web interfaces for these, or in the case of Sendmail, leave it to an expert/someone competent.
I can see why a complete novice with a new box might find it useful, but for any remotely complex setup, it's woefully inadequate...
The point of the roadshow is to tell people who ARE NOT THERE what they missed, and to make SCO appear to be a big, vibrant operation that requires road shows.
Damn, if only this crowd of thousands of technology geeks could muster up a single video camera between them... No, I suppose that's just crazy talk....
... is that all the CPU's instructions will take between 100 & 500 clock cycles to execute...
Yes, only in the USA would people do this. That's why I never receive spam from Asia, Africa, or Europe. Your knee-jerk anti-americanism is as bad as the spammers' greed, I'm afraid.
Uhu, funnily enough all the spam (I see) coming from Asia tends to be advertising American companies. The only spam I get from Europe is Russian Pr0n, with some scammers posting from Africa. I'd say the overwhelming majority is from US sources or advertising US "companies" (>95%).
I call bullshit here. I regularly set up Linux Samba servers (file and print) that work fine with Win98, NT, 2K and XP machines. Both standalone and as domain members. I've used both the normal smb password file and LDAP passwords for authentication, and it all works faultlessly.
In fact I'm sitting at an XP machine right now that's mounting from 3 different Samba servers...
Unless I'm missing something, this novel idea is complete garbage. Yes, sure you can disassemble the machine code, produce some C code from that and then recompile for a new target CPU but it's not going to work for the vast majority of applications.
The reason: hardware.
Even your average 80's arcade machine relies upon custom hardware for virtually everything. The main program spends most of its time simply adjusting registers to control sprites etc, and reading from hardware to detect collisions and so on. This new code you've generated for a new CPU will still expect the same supporting hardware...
So, how did you get the advance copy for a review?
He probably downloaded it off of Kazaa...
However if you work in an environment with mission critical apps that cannot fail, you can't just simply "patch your systems".
I have to ask, why the hell would you be running anything remotely "mission critical" on windows in the first place???
Hmmm, but the question is: who's skull should it be?
I would have said Darl McBrides', but the bone is probably so thick you'd have trouble fitting anything larger than a single 186 CPU in there...
Actually, that explains a lot...
Of course you're correct, IF we assume transportation, storage and marketing all cost zero. AND we assume no units will ever break-down, nobody will ever need support, and the product never requires any kind of bugfix (software or hardware) in its entire lifetime... So, if all that is correct, then so are you...
I agree that it won't do well, but for different reasons:
(1) All games consoles, including handhelds are sold at a loss, with the expectation that the licenced software sales will more than recoup the hardware costs. Nokia are not doing this - they are charging full price for the hardware, and then leaving the developers free to charge full price for the software. Nintendo and co can't lose so long as they produce great games, or profit from the 3rd party developers, but Nokia, as a hardware-only company don't have this revenue channel.
(2) The hardware in that phone is virtually identical to the 7650 and 3650 Nokia phones, which are considerably cheaper. These already have very large software catalogues, and the userbase to encourage developers to write new games for them. Producing cartridges for a single unproven platform is VERY risky for a company, so any games for the NGage will likely be slightly enhanced (if at all) versions of the games for the other 60 series phones.
It refuses to use my good sound card and instead uses the on-board card. Etc. etc. etc.
Just a quick idea: Why not disable the onboard sound chip in the BIOS? Or maybe just build the kernel without the driver for the motherboard chipset (or delete/disable the existing driver if it's a module)?
I've been following the news at Groklaw regarding SCO for some time now, and have submitted stories to /. several times (all rejected of course). The evidence has been piling up - shady companies pumping money into SCO despite the overwhelming bad news, directors appearing to be blatantly pumping stock prices. Third parties spewing FUD like no tomorrow. Personally though, I'm convinced Sun is playing a big part in working the SCO sock-puppet, not just MS...
"It's like a house that hasn't been maintained in a few years," McBride said. "We're going to come back and spruce the place up."
For some reason I have this image of some dungaree-wearing, straw-chewing hick pulling up beside a Porsche in his rattling, dented, rusting 1950's pickup, belching black smoke and yelling over "Hey boah, wan't me ter help yuh fix that ther car o' yors up? Ah'll only charge yuh 2 billion bucks! Yeehaw!"
DHTML is a Microsoft creation and is not part of any recognized standard.
How on Earth was this modded up as informative? Sure, it informs us that rossz is totally ignorant about this subject, but DHTML is definitely NOT a "Microsoft creation". Netscape 4 had DHTML capabilities well before the first capable MS browser (IE4) appeared.
DHTML stands for "Dynamic HTML". It's the result of manipulating the browser DOM using a scripting language (virtually always Javascript).
[Microsoft security flaws comparable to car maker design flaws]
A more apt analogy would be Ford making a car with a radio so defective that the car would explode if it received a signal of a certain frequency.
Your analogy is flawed. Ford wouldn't continue to sell cars from the dealer forecourts with the "exploding radios". You think PC World, or any other store (online or otherwise) send all the unpatched copied back to Redmond after an alert?
There's that, and the fact that Microsoft's search engine is the default page when IE tries to visit a broken link/dead site. Many people I know use MS's search engine simply because it's the default, and they don't realise there are far better alternatives out there. These same people are usually very pleased when I set up Google as the start page in their browsers ;-)
Dude, if you'd ever had to work with CDE (Sun's desktop) on Solaris, you'd realise ANYTHING is better! (And yes, I have had to!)
In my case, the vast majority are Excel files, which I explained above. However, it can also generate graphs and charts when required. These can be used standalone, or inserted into the spreadsheets.
Of course, it takes slightly longer to set up a new report this way (although a lot of the code is pretty reusable), but it pays off when you convert a report that's generated many times a day, or there are many reports to generate.
For more speed, I can often get away with CSV files for the output - reducing (in one case) a report from 45+ minutes to 17 seconds - sure, it's not quite as pretty, but it was much more current, and could be generated every 5 minutes instead of 5 times a day...
(As an aside, I tried both perl and php scripts for this, and perl is twice as fast even when running almost identical code - the DB query takes the same amount of time, but subsequent processing is much faster).
Try the DBD::ODBC module if you're using perl...
SpamProbe can be fooled by clever spammers who insert lots of common words in non-visible html.
Well it's not that clever, I've configured SA to mark obfuscated mail +20, so it's always caught immediately. The only people using this feeble trick are spammers, so there's no likelyhood of a false positive...
Actually I use the Open-Office spreadsheet quite a bit at work, and can't see any reason to change to be honest. Part of my job involves perl scripts that generate .xls spreadsheet reports at night for users to view the next day and my tests with OO render them exactly the same as the users see them with Excel.
;-)
BTW, the reason we switched to doing this was due to the old system; where Access was running on PCs, and generating reports was so damned slow! It may seem unbelievable, but changing from Access+MySQL (we replicate from our Oracle server for reports and other stuff) to Perl+MySQL on Linux resulted in a staggering increase in speed. Reports that were taking an hour are now completed in under 2 minutes! The method I use to convert from Access->perl is, firstly take the Pseudo-SQL Access generates, then customise it a bit for MySQL, then use the Spreadsheet::WriteExcel module for perl. It's great!
I've never used Access myself BTW, and don't really understand what the hell it's doing to use all the CPU cycles. We watched it's activity one day - it ran a query on the Linux box, which took 12 seconds (monitored it with "top"), it then pegged the Windows PC - a P4 2.4ghz - running Access at 100% load for a good 20 minutes generating a spreadsheet!! WTF?!
So, to anyone else suffering with slow Access reports, learn some perl
I'll take your SCO OpenServer and raise you an HPUX 11 as shittiest unix. Luckily we also have Linux machines at work, so just nfs mount all of its directories (no_root_squash ;-) so we don't have to use it's braindead tools most of the time... Having to rebuild the kernel after a memory upgrade?! WTF? The sooner we can get the two pieces of software on there (one of which is Oracle) moved to Linux the better...
</Rant>
that SCO is just completely insane...
Maybe not insane, but a bunch of very very greedy crooks. After all, they've seen a huge rise in their share price today (up 21%!)...