Then you've been talking to the wrong sysadmins. I'm not going any further with this as it looks like a complete troll.
In any case, there are valid points raised by both the preceding posters. Yes, Novell allows remote putzing about with machines; if the admins are causing a problem with it, you need to get your change control procedures right; it's a people problem, not a technical problem.
As for developers, yes, they should have seperate machines for testing on, ideally not connected to the rest of the network; you don't want to run untested code on a live network! For every intelligent developer, there's half a dozen who have posterior/elbow differentiation problems. Given how easy it is to learn VB, are you surprised?:) --
We use Novell/NT here, and remote administration is absolutely brilliant.
If we remote control a user's PC, we don't have to leave our desk to fix a problem on a computer at the other end of the building. If it's something complicated, we can do the work from our desk, without having to tell the end-user how to do it.
As an example, we had a new member of staff yesterday who had to have email set up. Rather than tell her "type this in this box, then click on OK" (after figuring out which box it is...) I was able to type in the details from my desk and only had to get her to type in her password. The email program was set up in about a minute; doing this by talk-through would have taken at least double that.
In short, you save on staff time, so you don't need so many staff (ie, savings for the company). The staff don't get so stressed (have you tried talking someone through tech support?) as well.
The only potential downside is that staff don't get as much exercise as they don't have to leave their desk, possibly leading to eye-strain (staring at the screen all the time) and other problems. These can be alleviated by rest breaks and properly designed workstations. --
Bzzzt! There was a buffer overflow in pine a while back which was potentially exploitable. In short, you could send a message with a sufficiently long Subject: line and overflow an unchecked buffer.
In true open source style, the bug was fixed pretty quickly and recent versions are, AFAIK, safe. --
Yup, Netscape is crap. I did up some pages using CSS2 and NS really barfed on them; black text on a black background is not good. I had to do some server side mojo to get it working.
That said, sites should attempt some kind of browser agnostic approach; there are some users for whom IE just isn't an option; linux/Unix users (let's ignore IE for Solaris/HPUX; it's even worse than NS), phone users (as someone mentioned elsewhere), etc. You are effectively telling these people they aren't good enough for your site.
If someone pulled that on me, they'd get a mail telling them to wise up and if they didn't, they'd just lost a reader. This is especially true of shop sites; if you are excluded from that site by dint of browser choice, email them to let them know why you won't be shopping there and you won't be recommending it to your friends. Vote with your credit card! --
15GB? Lightweight!:) We have a 70GB RAID partition on our Solaris server. Having a journaled file system on that (Solaris 7 has UFS logging) makes life so much better on hard reboots (like when someone kicks out the power cable; grr....). The previous server could take 20 minutes to fsck about half that disk space; now it just boots up without any trouble.
This is why linux has not been the enterprise choice; when it costs you x thousand dollars for a minute of downtime, you want that server back up as quickly as possible. Now we just have to have the FS war; ext3, reiser, jfs, xfs....:) --
There are several SID emulators out there, most notable Sidplay. There's also the High Voltage SID collection for those seeking some nostalgia on the old games. --
Part of linux's problem has been that making linux scale better (and hence run better on servers) makes it less efficient (more overhead to handle certain things), and worse on low-end hardware. Unless you have a code fork or manage to make it a kernel compile option, linux will continue to only be optimised properly for low-end hardware.
I don't understand the exact nature of the problem, but that's what I've gathered from various postings on web sites and Usenet. --
If it's done right, you'll manage to get a fair few *nix apps compiled. Ok, so a lot of the X-based stuff isn't gonna work, but people have already got apache and stuff running on it. --
I'm not sure if OSX will overtake linux; at least not until the (heavily rumoured and currently vapourware) Intel version is (possibly) released. I don't currently have the space or cash for a Mac, especially not given the system requirements OSX needs (what was it, 128MB RAM, 1.5GB disk?).
In any event, adding decent intel support would add a lot of potential consumers who might be willing to try it out but don't want to buy a new machine to do it on. Any half-assed attempt would, however, turn people off of it even if the problems subsequently got fixed. --
Try Amanda. It's free, runs under most versions of *nix and will even back up SMB shares (if you have samba installed). It is also fairly intelligent and will run different levels of backup depending on how much has changed on disk (eg, if not a lot has changed, it'll do an incremental; if a lot has changed, it might as well just do a full dump etc).
We use it here to backup our Unix stuff and it rarely needs poking; it just chugs away in the background and the only intervention we have to do is change tapes every day (which you'll get on any backup system without a tape array). --
I guess there's a fine line between "humour" and "trolling". Personally, I found it funny, but I'm interested to know who modded it up as "informative"! --
We use it under Solaris here, and it works OK but I've seen it get wedged in some circumstances. It does seem to be reproducable as it always gets wedged under one specific user's home drive, but I haven't had time to hammer it out properly to submit a bug report to McAfee.
BTW, I've found it works an absolute dream using qmail and qmailscan (both packages available from qmail's home page) and has stopped a lot of viruses being sent via email. Qmailscan also stops attachments with certain extensions; in my case, I set it up to block.VBS and was very glad when it stopped an ILOVEYOU variant:) --
Just because there's no innovation doesn't mean it's a bad idea; large chunks of processor design and algorithms still come from the early 70's and are still valid. That said, there may be a revolution in cache design just around the corner... --
Check www.spec.org; in short, Intel just got kicked into touch. A new US III 900MHz workstation is getting over twice the FP performance of a roughly equivalent Intel chip. --
That's for applications; I'd be surprised if sparc/linux works perfectly without some tweaking. Bear in mind, part of the Solaris 8 release was to add support for US III chips. --
Well, the source will be open, so there's nothing to stop BSD'ers from snarfing the source to port to BSD provided they can get past the licence infection of GPL->BSD. In short, it's probably going to be up to some developers hacking with it. --
WTF? What overhead are you talking about? UFS has way more overhead than TMPFS for various reasons. In any case:
jr:air% cd/var/tmp
jr:air% time dd if=/dev/zero of=afilename bs=512 count=10000
10000+0 records in
10000+0 records out
dd if=/dev/zero of=afilename bs=512 count=10000 0.24s user 1.98s system 29% cpu 7.537 total
jr:air% cd/tmp
jr:air% time dd if=/dev/zero of=afilename bs=512 count=10000
10000+0 records in
10000+0 records out
dd if=/dev/zero of=afilename bs=512 count=10000 0.14s user 1.45s system 65% cpu 2.440 total
Ie, tmpfs is over twice as fast as UFS. And that's with UFS logging enabled which generally increases the speed.
For reference, this is a SPARCstation 5/170 running Solaris 7 and the memory is pretty much full, so/tmp is probably using the disk swap by now. --
At least, the/tmp bit. Under Solaris,/tmp is effectively part of virtual memory (used to be just swap space, now includes physical RAM). Causes several problems as:
files disappearing from/tmp on reboot which users didn't expect
large files eating up swap space
Personally, I find it a great idea; just some admins don't like it as much. --
Slashdot Mirror
In any case, there are valid points raised by both the preceding posters. Yes, Novell allows remote putzing about with machines; if the admins are causing a problem with it, you need to get your change control procedures right; it's a people problem, not a technical problem.
As for developers, yes, they should have seperate machines for testing on, ideally not connected to the rest of the network; you don't want to run untested code on a live network! For every intelligent developer, there's half a dozen who have posterior/elbow differentiation problems. Given how easy it is to learn VB, are you surprised? :)
--
It's a fair point about in-house vs external support, but if you can overcome the trust issues involved, it makes life a lot easier.
--
If we remote control a user's PC, we don't have to leave our desk to fix a problem on a computer at the other end of the building. If it's something complicated, we can do the work from our desk, without having to tell the end-user how to do it.
As an example, we had a new member of staff yesterday who had to have email set up. Rather than tell her "type this in this box, then click on OK" (after figuring out which box it is...) I was able to type in the details from my desk and only had to get her to type in her password. The email program was set up in about a minute; doing this by talk-through would have taken at least double that.
In short, you save on staff time, so you don't need so many staff (ie, savings for the company). The staff don't get so stressed (have you tried talking someone through tech support?) as well.
The only potential downside is that staff don't get as much exercise as they don't have to leave their desk, possibly leading to eye-strain (staring at the screen all the time) and other problems. These can be alleviated by rest breaks and properly designed workstations.
--
I wondered the same, but there's a post above (ie, it's been modded up to +5) which says the poster changed the image after the submission.
--
In true open source style, the bug was fixed pretty quickly and recent versions are, AFAIK, safe.
--
Surely you mean insecurity settings? :)
--
--
That said, sites should attempt some kind of browser agnostic approach; there are some users for whom IE just isn't an option; linux/Unix users (let's ignore IE for Solaris/HPUX; it's even worse than NS), phone users (as someone mentioned elsewhere), etc. You are effectively telling these people they aren't good enough for your site.
If someone pulled that on me, they'd get a mail telling them to wise up and if they didn't, they'd just lost a reader. This is especially true of shop sites; if you are excluded from that site by dint of browser choice, email them to let them know why you won't be shopping there and you won't be recommending it to your friends. Vote with your credit card!
--
This is why linux has not been the enterprise choice; when it costs you x thousand dollars for a minute of downtime, you want that server back up as quickly as possible. Now we just have to have the FS war; ext3, reiser, jfs, xfs....:)
--
There are several SID emulators out there, most notable Sidplay. There's also the High Voltage SID collection for those seeking some nostalgia on the old games.
--
Just remember, monks rule! :)
--
I don't understand the exact nature of the problem, but that's what I've gathered from various postings on web sites and Usenet.
--
If it's done right, you'll manage to get a fair few *nix apps compiled. Ok, so a lot of the X-based stuff isn't gonna work, but people have already got apache and stuff running on it.
--
In any event, adding decent intel support would add a lot of potential consumers who might be willing to try it out but don't want to buy a new machine to do it on. Any half-assed attempt would, however, turn people off of it even if the problems subsequently got fixed.
--
We use it here to backup our Unix stuff and it rarely needs poking; it just chugs away in the background and the only intervention we have to do is change tapes every day (which you'll get on any backup system without a tape array).
--
I guess there's a fine line between "humour" and "trolling". Personally, I found it funny, but I'm interested to know who modded it up as "informative"!
--
BTW, I've found it works an absolute dream using qmail and qmailscan (both packages available from qmail's home page) and has stopped a lot of viruses being sent via email. Qmailscan also stops attachments with certain extensions; in my case, I set it up to block .VBS and was very glad when it stopped an ILOVEYOU variant :)
--
Just because there's no innovation doesn't mean it's a bad idea; large chunks of processor design and algorithms still come from the early 70's and are still valid. That said, there may be a revolution in cache design just around the corner...
--
Heh, close; check this page for why...
--
Check www.spec.org; in short, Intel just got kicked into touch. A new US III 900MHz workstation is getting over twice the FP performance of a roughly equivalent Intel chip.
--
That's for applications; I'd be surprised if sparc/linux works perfectly without some tweaking. Bear in mind, part of the Solaris 8 release was to add support for US III chips.
--
Well, the source will be open, so there's nothing to stop BSD'ers from snarfing the source to port to BSD provided they can get past the licence infection of GPL->BSD. In short, it's probably going to be up to some developers hacking with it.
--
Yeah, looks good, but doesn't support >8GB disks :(
--
For reference, this is a SPARCstation 5/170 running Solaris 7 and the memory is pretty much full, so /tmp is probably using the disk swap by now.
--
- files disappearing from
/tmp on reboot which users didn't expect
- large files eating up swap space
Personally, I find it a great idea; just some admins don't like it as much.--