"What do you think of allowing normal FTP logins? Doesn't it just beg for password sniffing? Although not as convenient would it be better to make users tunnel through SSH for FTP?"
1) To sniff, you'd have to be in a direct route between the user and the server. The likely hood of this over the internet is rare, at best. Unless, of course, you compromise one of the ISPs.. Which leads to
2) The user is chrooted into their own home directory by the ProFTPD configuration. The only thing they can change, would be the files in that dir. Even if they magically broke out of the chroot jail (impossible, AFAIK), they would still have normal Unix file premissions stopping them from changing random files.
In this case, encrypted FTP does not show a significant benefit for a great deal of effort. I still suggest my original premise of seal-box with normal FTP access for all, and SSH for one. ---
First off.. Do not just "Scrub" the system. Wipe the HD, LLFing if possible. Backup data files first, via the network to a known good server first (via anon FTP so any remaining sniffers, etc, will not read any important password).
Then go and reinstall a recent Linux distro. I recommend Slackware. It may not have the bells & whistles of Red Hat, but its BSD-style init scripts are easy (easy as config.sys and autoexec.bat) to learn, and tends to ship with reasonably secure daemons. Of course, OpenBSD is another possible solution:-)
Now, if you want to just give them FTP access (and nothing else), ProFTPD provides a nice solution. Granted, earlier versions had some interesting security holes (poke), recent versions have been a lot better security wise. Set it up with mod_linuxprivs (which uses the POSIX.1e interface of 2.2.x and later kernels to drop all root privs except for the ability to bind to ports less than 1024). (For the configure impaired, try "./configure --prefix=/usr --with-modules=mod_linuxprivs").. This lets them have ftp access (I'd also recommend you setup ProFTPD to chroot the various users to their homedirs). Disable telnet. Install SSH or OpenSSH and only allow your own login to use it (login.access allows this). Only allow your user to execpt su (perhaps as part of the wheel group), and have your root password as something other than your normal account password. At this point, you will have a secure system, FTP access for normal users, and secure remote access for your own administration. Of course, this doesn't get you out of your duties to monitor Bugtraq for possible advisories. I also recommend (very much so) that you read LASG -- the Linux Administrator's Security Guide. It's very good:-) ---
I've been reading the threads and comments and thinking about this a lot. What people seem to be missing is that fact that we could implement what most people need with little effort.. It's only the odd few percent odd-ball situations that a lot of people are focusing on.
VGA-16 colour support in 640x480 (ie: an video card and monitor that can handle this is likely to be on the target machine), so GUI config tools are quite possible from the earliest get go.
Here's an idealised setup routine:
Start install from either bootable CD, or a ~5mb disk image loadlin'd from a DOS prompt. This gives us the space for the bare-bones GUI tools and abilities.
Choose your prefered method of install (guru text, or newbie gui).
Partition the HD (either in text mode via an Guru fdisker, or in VGA16-640x480 with a friendlier face). Choose your swap partition and target partition.
Pick packages in your choice of guru Slackware-like expert mode (slick & fast), or the incredibly slow Red Hat custom mode (GUI).
Decompress packages.
Guru install then has a network config and lilo setup. Newbie install goes into the Setup Wizard *. The setup wizard allows easy setup of XF86Config (in/etc), setup of your network (if it exists), and an easy walkthrough of Lilo (as well as a rescue disk of some kind).
The setup has completed with a bootable system.
* Setup Wizard is a version of netconfig and the lilo conf with the "click for help and examples" and related documentation all in one interface, allowing easier first time setup.
For an idealised setup like this to happen, there need to be a few more tools that don't (AFAIK) yet exist, as well as a few modifications to existing tools. X, for example, should default back to the VGA16 colour server if it suddenly finds the video card is different (ie: the 3Dlabs server is run on a non-3DLabs card). A simple program that is set to run in the default system-wide xinitrc can detect the fallback, and open up a helpful wizard for newbies. For non-newbies, it can allow skipping of the dialog so they can get to fixing the problem themselves.
Another thing would be a good program for setting up your XF86Config for the first time. xf86config is kinda complex and lengthy for a newbie. Since the kernel knows about the hardware, how hard would it be for a program to check the/proc export, then probe the monitor. Once it has the info, it could query the user to confirm it, and then test it. It'd be faster than things like xf86config.
Finally, a nice program I'll call "Control Panel" needs to be created. Yes, it'll be a blatant rip-off of the Windows control panel concept (which, IMO, is actually implemented semi-decently). A "Container" window is shown, listing the various configuration backends it understands. IE: for networking, it'd probably want an xml file describing how to obtain its settings, how to committ its settings, and how to format its GUI dialog. This could be implemented in GTK+ with libxml and included in the system menus of the various window managers and desktop environments that ship with the system. What would absolutely have to be shipped would be the basic complement of backends: X display settings, networking,/proc info parser, kernel configuration, package manager **, keyboard settings (rc.keyboard?), mouse settings (rc.gpm), font manager (TTF support in X), "multimedia" (config for sound cards, and 3D accelerators, both of which have traditionally been hard to setup), "Startup" (a good GUI SysV config for us BSD init script people:^).. This should provide a good base for even the greenest newbie to go and figure out how to change things.. With the XML config system as the backend, it would be very easy to fetch updates and deal with changes.
** Package Manager: To my taste, there are no "good" package managers. Something that could keep track of how often certain packages are used, could handle the installation of autoconf, RPM, deb, and Slackware tgz through support programs, and could finally centralise all of these disparate ideas would be what I'm thinking of. NT 5 has something like this, and it suprised me when I was playing with it. It's butt ugly, but it really does track how often something is used -- a big plus.
The problem is, of course, the fact that there are hundreds of window managers, and a few desktop evironments to boot. Under Win32, the installation and removal of programs has been simplified because of the add/remove control panel applet. True, it did little but point the appropriate uninstall program at the appropriate install created setup file, but the Linux world does not have something like it. Remember, their add/remove applet handles all kinds of setup programs from different companies (install shield, MS, Norton setup programs, etc). Second, the "control panel" is reinvented poorly by desktop environments like Gnome and KDE. Their internal config programs are great for modification of their own startup, look & feel, and window manager, but they do not address things like network config, kernel reconfiguration and compiliation, etc. The things they do allow you to look at are limited. KDE's "SMB status" tab is interesting, but you can hardly reconfigure smb.conf from there, or do something like launch Swat and connect to it in a browser.
If you've not noticed, all my ideas for "new" programs, or modifications to existing programs, involve ways for these many disparate ideas and design philosophies play nicely together. An "over" package manager that allows the user to point it at a package (or various types), and letting it handle the implementation (calling rpm, installpkg, or configure --prefix=/usr; make; make install; recording the changes and monitoring usage) would do much to make life easier for both the newbie and the guru alike (in my "over" package manager, the guru would be able to easily modify the default config "template" args, supply their own args, etc). For things like X, there would be a way to figure out problems, and help the user cope with them (rather than "vi/etc/XF86Config, and have fun!"). The basics are in place, and the source code is available. Implementation is not the issue -- it's only getting people to agree on the same basic method. The one true method. The Linux Kernel has advanced because of Linus' vision, now we need a Linus for the userland tools for maintaining the systems.
I think your patent on the Highhiker's Guide infringes on my "trilogy in n (where n != 3) parts" patent. Please cease and decist your usage of this patent. If you ban rap music (as you hold the patent on it), I'm sure I can overlook your use of our non-obvious "trilogy in n (where n != 3) parts" patent, and give you a licence.
In another side deal, I'll let you in on my "conics" patent if you let me in on the trig identities.. ---
"SPARCserver 690MP (4x180MHz, 512MB RAM) and two SPARCstation 10s...4x18GB diff SCSI in the 690...They claim they do this because of high school kids digging in the trash, what a load of BS."
Exactly. If I knew that was in the trash, I wouldn't hire any shifty highschool kids -- I'd jump in myself! New firewall, two new workstations, and more pr0n storeage.. yeeeehhhaaaaw!!!! ---
Why are you yelling at the yanks? Don't make us Canadians look bad, m'kay?
Your posting doesn't have anything to do with the topic of the RIAA becoming pissy over the "my.mp3.com" stuffenpuffel, unless you count "greed" as relating it (it's weak, at best). ---
"It is a well-known fact that Linus Torvalds used MS-DOS's EDIT.EXE to write the initial bootstrap assembly code for Linux."
Maybe yes, maybe no. Either way, edit.com is a thin shell over qbasic.exe (well, it was back in 1991). Before we pay homeage to Bill for providing Linus with his bootstrap code editor, we should perhaps also say a thanks to Mr. Paul Allen. He, too, worked on the Microsoft basic internals. I doubt QuickBasic (and QBasic) were actually "blessed" by the hands of Bill or Paul, as Microsoft was larger by then.
As for you comment about "if there was no Microsofft.." You might have a point, except a vacuum cannot sustain itself. There would have been another company, another "prince," another text editor. IBM was talking to many people. If Mr. Gates had been shot, would we have been using CP/M 80 for the past decade? What about the fellow who originally wrote DOS -- would he have become the prince? Microsoft did help, but then anyone could've stepped in as the vacuum would've been filled eventually. And Linus could've just as easily edited the bootstrap code in WordPerfect:^)
"Gates truly is a prince. Do you really want to defy the prince?"
I'd at least want him to sign a Magnacarta, forbidding him from bundling that fscking IE.. It's a bit late, though, I've already jumped ship to Linux:-)
"NT uses security throughout the system on objects. It's then way more flexible to set security flags, without the necessity to open up the system because a certain daemon needs root access, for example."
1) Linux supports stuff like this via POSIX.1e, which allows you to flexibly drop what you don't need (super user wise). An example is ProFTPD, which has mod_linuxprivs. When it's used, ProFTPD loses all super user abilities, except for the binding to ports lower than 1024 one. 2) More complex does not mean better. During WWII, German artillery had 49 moving parts and could strike more accurately, whereas American artillery only had 9 movings parts -- it's only feature was it broke less:-) The K.I.S.S. principle applies doubly to security. Keeping track of more possible permutations of security aside, MS is not targetting this enchanced security model at people who understand it -- "Learn Windows NT in 21 Days" has become the rule of the day, which means it's wasted and (more often than not) leads to more problems than it solves.
"MS fixes security leaks within 24 hours most of the time. Arguing it takes ages to get a fix are therefor unfounded."
It doesn't take ages to get a fix.. It just takes ages for them to post it on their website. They do really have a long latency time between a patch, and a posted patch.
"IE holes are a problem, but who surfs the net on a production server. "
Except that IE is now integrated into many other applications that don't need it (I've tried NT 5, and I really hate the grey-child-like Notepad common dialogs which huge "My Network Friends" buttons, and webenabling).. When you take an insecure code base, and cram it everywhere to stop people from ripping it out, you compromise a lot more than your morals. Then you have the marketdroid angle -- NT 5 Work^H^H^H^H Professional (where's the non-professional?) is targetted at those people who like saying they're using the "professional" version. I betcha they surf the web lots.. Do you want your CEO to go and get BOed because of their workstation OS choice?
"MS provides a bulkload of security documents how to implement security on your servers."
I'll have to go with Theo (de Raadt) on this one, and say ship the default config secured -- don't document what you have to do after the fact. When you have to install 500 workstations with a secure setup, it doesn't pay to have to go to each one and click on the same frickin' security wizards, over and over. There are ways around this, but I don't know why they don't ship with more things turned off, or at least with a visible off switch. I received some funny emails from my IDS when NT 5's probing of port 445 ("microsoft-ds") on the Linux firewall set it off..
NT 5 is better, but the ideas behind it are a mishmash of idealistic engineering, hopeful marketting, and sadly failed implementation. As the users on Bugtraq said, "it's getting better [with things like run as alternate user], but it still has lots to catch up on compared to Unix."
Hopefully it will require the physical changing of a jumper on the motherboard + a special bootdisk to flash the translator units.
Flash rom BIOSes often don't require this, and video BIOSes and SCSI BIOSes are just as vulnerable in the real world, yet they aren't (to my knowledge) often taken advantage of by viruses or trojans in the wild. Any modern operating system restricts access to the hardware, so it'd take a bootdisk to put the machine into real mode before it would likely be able to flash.
"Although Transmeta has a 128bit chip, they still emulate the x86 instructions, and are completely reliant on Intel setting standards."
I addressed this in another thread. So what if Intel decides night is day and white is black? It will only affect their instruction sets. If Intel goes and reverses the order of the argument bytes to the mov instruction, all they hurt are themselves. AMD and Transmeta both carry the x86 ISA torch along side Intel. They'd have to resort to another method to beat them, which leads...
"Suppose Intel doesn't want to let Transmeta in on a prerelease stepping of the Merced chip?"
Intel has said before that the Merced is a 64-bit VLIW chip with a "powerful" core. In fact, they set the pricing point to be around 5 to 6 figures. I really don't think that'll clash with a low-end designed for embeded marlet processor, which uses a different simplified 128-bit VLIW core. The ol' x86 ISA doesn't get a look in anymore:-) Besides, this has never posed a problem for AMD.. Being first to market doesn't always mean being best to market (K7 vs PIII).
"Penultimate is not just a fancy way of saying ultimate. It means second-to-last."
Would you, in this day and age, ask if it ran Quake first?
I'd first ask if it ran Quake 3: Arena, then Unreal Tournement, etc, on down the list.. Until we hit Quake. After Quake, I'd ask if it ran Doom. So, it really is second to last;-)
[Being flamed by you is nifty, kinda like that 48 hour period where I read your all of website] ---
"since it is maintaining compatability with x86 instruction sets, it will always follow Intel's lead (and require Intel to continue leading) mainstream chip technology."
This is like saying that because GM is making cars, they have to follow Ford's lead in how to make them. The x86 ISA is pretty much developed right now, with instructions for anything you'd care to do in silicon (or emulation). Since Intel has said that their next proc is VLIW, it looks like TransMeta's VLIW proc is leading them...
"It will never run as fast as a native x86 chip would (because it must execute extra instructions). Of course, being smaller and independent to the hardware, these chips may be made significantly faster (clock-wise) than mainstream CISC/RISC chips and comparatively match performance. But not yet."
The purpose was never performance, or the masturbatory RISC/CISC debate stuff. Its purpose is to provide good performance for insanely low levels of power consumption.
"No mention was made regarding the connection to the Internet...that was just assumed to be there. But I have yet to hear about any affordable and sufficiently fast connection via mobile unit... How will they address this, or will they just leave it up to other companies to solve this general problem?"
I think you are refering to the fact that the translation units can be upgraded via software. Software which comes over the internet:-)
"However, Linux does not have a standards-conforming browser (i.e. IE) available until Mozilla is complete. "
(sarcasm in good humour) Christ, what've I been running? Jeez, I guess it was just Bill himself pushing a cloaked IE through my net connection onto my desktop, as I can't be running something that's not been released.. (/sarcasm in good humour)
This will make a very nice "web panel" device, like the one Cyrix promoters were pushing.. I know I'd love to replace my 486 X terminal with a wireless laptop display:-) ---
"I thought they would focus that as a "feature", not a mainstay of their product."
It is a feature. Did you not digest any of the info about the translation unit? It can emulate any ISA you care to specify.
"I am disappointed to see the archaic and outdated x86 architecture perpetuated by what I once thought to be a high-tech company on the bleeding edge"
I am disapointed you wasted time whinning about an ISA with a firm foothold in the world. Given an OS like Linux, you can swap processors as much as you want (ie: it's a commodity), but not everyone is using Linux.. In fact, of the 400 million (or so) Windows installations out there, I'm willing to bet a fair number of them are running on a processor that runs the x86 ISA at some point. A lot of other OSes also can run on it, like BeOS, Linux, *BSD, etc. If you don't like that fact, go buy a G4 or an Alpha, and support alternative processors. Whinning about it on Slashdot is like showing up at your local video store, and whinning about how they don't stock Beta, and why VHS is so much worse than Beta..
"AXP, sparc or even MIPS has a better architecture than the x86."
"Too bad it sounds like they expect nothing to be written in Crusoe's native language... There must be some speed improvement that could be gained, if say, Crusoe's achieved 40% market share in the notebook market, that would make it worthwhile for developers to create Crusoe ports."
I can't believe the number of navel gazing, performance lovers who keep saying this (or maybe I can, it's the same crowd that crows about K7 native RISC stuff).
My reply to that line of thought (the tin god of performance over all else): "If you want performance, don't use userland apps -- they use bloated things like Java, and C++. Implement it in kernel space. Oh, and don't use C, use ASM. C has too much overhead. If you really want space, just write the specific task you want into the boot sector the floppy or HD. Of course, since it's just one task, you can dump uneeded things like interface libraries or a BIOS...."
And the reason why: You lose flexibility when you remove the translator: 1) You now must recompile all apps. 2) You can't fix the any erratum in software any more 3) You are stuck with that VLIW core, instead of having a core you can extend up the ying-yang. 4) You can't profile the program running as it runs, and get speed boosts or power consumption benefits anymore.
The purpose is not performance. You might get hard thinking about a 1Ghz K7, but the fact is that the ram, HD, bus speed, and other parts of the computer are no where near the 1Ghz line. You're getting increasingly less of a return as you go up the Mhz ladder. The purpose of the Cursoe is flexibility. Now you have a 400Mhz proc which can emulate any other proc around a modular core, and it can profile apps, and it can live without a fan.. It is the perfect processor for embeded things like smart houses, and it does make the Palm's Dragon Ball look anemic in terms of performance -- you should like that part. The best thing is, I can also run it on a desktop with the "slow" peripherals, and it's still bitchying fast, and now allows software overclocking (as power consumption is taken care of). So even if they aren't targetting it for it, it also has the potential to be the fast thing running on electrons -- and that's because it is flexible, not performance oriented. ---
Ahh, the penultimate question of the ages -- will it run Quake.
Itchy reply finger, meet my itchy trigger finger..
Even with the site and 'cast asside, this is a laptop processor. Nothing says Quake can't run on a laptop, unless the laptop is an iBook or something. But the Cursoe proc emulates x86 ISA... So the answer is a simple 0x44 0x75 0x68..
The N64's ram is expandible, and the raw processing power of the beast is not to be toyed with (consider its cost). Ever opened up the beast and played with the memory expansion card? (I have)..
Use an ISA or PCI card that connects to the plugin, and you can use your PC's ram and HD space as memory for the thing, as the design allows the cartidges (or, in this case, computer) to contain things like expansion ram, and extra processors. You may see it as limited, but it is very expenadible, and hackable. ---
"VERY low power consumption, somewhere around 1 watt during normal use. Less than a few milliwatts for "standby" mode. You can leave this thing on for weeks without difficulty. On a battery."
"It's the code-morphing that makes it compatible right? Or is there some deeper compatibility at the hardware level?"
Unlike the PIII or K7, which have special microhardware to translate 32-bit x86 ISA to the 32-bit RISC internal cores, the Crusoe uses a hybrid hardware/software module (patenteded, et all) that translates the 32-bit x86 ISA into 128-bit VLIW core. The fact it's in software allows them to apply RAD techniques to their translation code, which is a big win, allows them to reconfigure the hardware based on the programs running for optimal power consumption, and allows software overclocking:-) This is the reprogrammible CPU we've all secretly lusted after... And because its core is VLIW, I hope we can leave behind those "[R|C]ISC is better" flamewars (which were really pathetic). The VLIW core is also very much simpler in design and cleaner (asthetically speaking) than either CISC or RISC. This is why the chip can be so cheap for the speeds they get, why it's so cool (pun), and why it uses so little power (more so inconjuntion with their translator).
"Is there any reason to believe that applications written natively for this would be able to avoid the code-morphing layer and run even faster?"
Nope. Unlike the K7 and PIII, the translation is important to the process. For performance, they likely have the translator units running at a fast enough speed that the VLIW core is kept as full as if it didn't have a translator unit. And without the translator unit, you'd have to spend a few more man years designing a new BIOS, chipset, etc, that understand VLIW, as well as a new instruction fetching unit. It's easier to support the x86 ISA (which everyone supports), and stick with the design they have now. Besides, as they have pointed out, the purpose is to have a reliable low power CPU, not an "oh my god, I came it was so fast!" processor. This is best accomplished with a smart translator that is software reconfigurable around a simple VLIW core.
This doesn't stop the idea of a very high performance VLIW core desktop machine, which is what Intel is lusting after with its Merced. Luckily, the Cursoe seems a lower-level version of the Merced, which should stop any Intel strangehold on the VLIW market. And when AMD extends the x86 ISA with 64-bit instructions, your Cursusoe from the ol' year 2000 will be able to handle it. Flexbile; extensible; cheap -- I like it. ---
"I don't support trademark enforcement on domain names. If this was Microsoft making people stop the selling, all the slashdot crowd would be up in arms."
If Microsoft didn't defend their trademark, they'd lose it. Same goes for Linus, and anyone else. I support Microsoft in keeping their trademarks under their roof, and support any normal business activity. I don't support the way they break the law, but don't confuse that with rampant zealotry.. ---
I'm sure a lot of us realised that, yes, these are the foul scum known as domain squatters. As well as the fact that the "nominal fee" listed on the page is a fee the domain squatters get. Linus is just trying to make sure they don't sell to every Tom, Dick, and IPO Jane out there.
This gets lost in the, "domains, Linus, lawyers -- oh my!" keyword stream of thought, which leads to rantings of hypocrisy. ---
Linus is forcing the squatters to not sell the domains. He owned the trademark first, and so he decides. This is a good thing, I think, as the squatters are just trying to profiteer on Linux(r)'s good name;-)
Etoy had their domain first, and Etoys grabbed their "eToys.com" trademark after, so the prior art bit kicks in. I'm sure if those squatters had bought the name before Linus held the trademark (say, in 1995), they'd be well within their rights to continue to sell them.
IMO it would set a dangerous precedent if Linus started wielding the trademark like a clue-by-four on any company that looked to make money from semi-legitimate (in the case of LinuxOne), and legitimate (in the case of Slackware, et all) businesses relating to Linux. The let them make their mistakes on their own, and let people realise that there are shady people out there.
It's a bit different when dealing with domain squatters, who are pretty close to spammers.. MO, of course:-) ---
Etoys who registered their trademark after Etoy existed is clearly in favour of Etoy.
SeriousDomains, a cyber-squatting group that buys domains speculatively and auctions them off to the highest bidder, bought these domaisn after Linus received the trademark. It's his decision on how they use it, and he's chosen to not let them make money from squatting.
Do you see the difference between a big company bullying someone who was already there, and someone who owned the trademark stopping domain squatting/auctioning which is likely a direct result of the recent $$$ IPOs? ---
Slashdot Mirror
"What do you think of allowing normal FTP logins? Doesn't it just beg for password sniffing? Although not as convenient would it be better to make users tunnel through SSH for FTP?"
1) To sniff, you'd have to be in a direct route between the user and the server. The likely hood of this over the internet is rare, at best. Unless, of course, you compromise one of the ISPs.. Which leads to
2) The user is chrooted into their own home directory by the ProFTPD configuration. The only thing they can change, would be the files in that dir. Even if they magically broke out of the chroot jail (impossible, AFAIK), they would still have normal Unix file premissions stopping them from changing random files.
In this case, encrypted FTP does not show a significant benefit for a great deal of effort. I still suggest my original premise of seal-box with normal FTP access for all, and SSH for one.
---
First off.. Do not just "Scrub" the system. Wipe the HD, LLFing if possible. Backup data files first, via the network to a known good server first (via anon FTP so any remaining sniffers, etc, will not read any important password).
:-)
:-)
Then go and reinstall a recent Linux distro. I recommend Slackware. It may not have the bells & whistles of Red Hat, but its BSD-style init scripts are easy (easy as config.sys and autoexec.bat) to learn, and tends to ship with reasonably secure daemons. Of course, OpenBSD is another possible solution
Now, if you want to just give them FTP access (and nothing else), ProFTPD provides a nice solution. Granted, earlier versions had some interesting security holes (poke), recent versions have been a lot better security wise. Set it up with mod_linuxprivs (which uses the POSIX.1e interface of 2.2.x and later kernels to drop all root privs except for the ability to bind to ports less than 1024). (For the configure impaired, try "./configure --prefix=/usr --with-modules=mod_linuxprivs").. This lets them have ftp access (I'd also recommend you setup ProFTPD to chroot the various users to their homedirs). Disable telnet. Install SSH or OpenSSH and only allow your own login to use it (login.access allows this). Only allow your user to execpt su (perhaps as part of the wheel group), and have your root password as something other than your normal account password. At this point, you will have a secure system, FTP access for normal users, and secure remote access for your own administration. Of course, this doesn't get you out of your duties to monitor Bugtraq for possible advisories. I also recommend (very much so) that you read LASG -- the Linux Administrator's Security Guide. It's very good
---
VGA-16 colour support in 640x480 (ie: an video card and monitor that can handle this is likely to be on the target machine), so GUI config tools are quite possible from the earliest get go.
Here's an idealised setup routine:
* Setup Wizard is a version of netconfig and the lilo conf with the "click for help and examples" and related documentation all in one interface, allowing easier first time setup.
For an idealised setup like this to happen, there need to be a few more tools that don't (AFAIK) yet exist, as well as a few modifications to existing tools. X, for example, should default back to the VGA16 colour server if it suddenly finds the video card is different (ie: the 3Dlabs server is run on a non-3DLabs card). A simple program that is set to run in the default system-wide xinitrc can detect the fallback, and open up a helpful wizard for newbies. For non-newbies, it can allow skipping of the dialog so they can get to fixing the problem themselves.
Another thing would be a good program for setting up your XF86Config for the first time. xf86config is kinda complex and lengthy for a newbie. Since the kernel knows about the hardware, how hard would it be for a program to check the
Finally, a nice program I'll call "Control Panel" needs to be created. Yes, it'll be a blatant rip-off of the Windows control panel concept (which, IMO, is actually implemented semi-decently). A "Container" window is shown, listing the various configuration backends it understands. IE: for networking, it'd probably want an xml file describing how to obtain its settings, how to committ its settings, and how to format its GUI dialog. This could be implemented in GTK+ with libxml and included in the system menus of the various window managers and desktop environments that ship with the system. What would absolutely have to be shipped would be the basic complement of backends: X display settings, networking,
** Package Manager: To my taste, there are no "good" package managers. Something that could keep track of how often certain packages are used, could handle the installation of autoconf, RPM, deb, and Slackware tgz through support programs, and could finally centralise all of these disparate ideas would be what I'm thinking of. NT 5 has something like this, and it suprised me when I was playing with it. It's butt ugly, but it really does track how often something is used -- a big plus.
The problem is, of course, the fact that there are hundreds of window managers, and a few desktop evironments to boot. Under Win32, the installation and removal of programs has been simplified because of the add/remove control panel applet. True, it did little but point the appropriate uninstall program at the appropriate install created setup file, but the Linux world does not have something like it. Remember, their add/remove applet handles all kinds of setup programs from different companies (install shield, MS, Norton setup programs, etc). Second, the "control panel" is reinvented poorly by desktop environments like Gnome and KDE. Their internal config programs are great for modification of their own startup, look & feel, and window manager, but they do not address things like network config, kernel reconfiguration and compiliation, etc. The things they do allow you to look at are limited. KDE's "SMB status" tab is interesting, but you can hardly reconfigure smb.conf from there, or do something like launch Swat and connect to it in a browser.
If you've not noticed, all my ideas for "new" programs, or modifications to existing programs, involve ways for these many disparate ideas and design philosophies play nicely together. An "over" package manager that allows the user to point it at a package (or various types), and letting it handle the implementation (calling rpm, installpkg, or configure --prefix=/usr; make; make install; recording the changes and monitoring usage) would do much to make life easier for both the newbie and the guru alike (in my "over" package manager, the guru would be able to easily modify the default config "template" args, supply their own args, etc). For things like X, there would be a way to figure out problems, and help the user cope with them (rather than "vi
Just my opinion
---
I think your patent on the Highhiker's Guide infringes on my "trilogy in n (where n != 3) parts" patent. Please cease and decist your usage of this patent. If you ban rap music (as you hold the patent on it), I'm sure I can overlook your use of our non-obvious "trilogy in n (where n != 3) parts" patent, and give you a licence.
In another side deal, I'll let you in on my "conics" patent if you let me in on the trig identities..
---
"SPARCserver 690MP (4x180MHz, 512MB RAM) and two SPARCstation 10s...4x18GB diff SCSI in the 690...They claim they do this because of high school kids digging in the trash, what a load of BS."
Exactly. If I knew that was in the trash, I wouldn't hire any shifty highschool kids -- I'd jump in myself! New firewall, two new workstations, and more pr0n storeage.. yeeeehhhaaaaw!!!!
---
Why are you yelling at the yanks? Don't make us Canadians look bad, m'kay?
Your posting doesn't have anything to do with the topic of the RIAA becoming pissy over the "my.mp3.com" stuffenpuffel, unless you count "greed" as relating it (it's weak, at best).
---
Well, all I can say is.. I smell arrogance, the double lattes of the marketdroids, old money, and those wonderful sweater things Mr. Gates wears..
:-)
---
"It is a well-known fact that Linus Torvalds used MS-DOS's EDIT.EXE to write the initial bootstrap assembly code for Linux."
:^)
:-)
Maybe yes, maybe no. Either way, edit.com is a thin shell over qbasic.exe (well, it was back in 1991). Before we pay homeage to Bill for providing Linus with his bootstrap code editor, we should perhaps also say a thanks to Mr. Paul Allen. He, too, worked on the Microsoft basic internals. I doubt QuickBasic (and QBasic) were actually "blessed" by the hands of Bill or Paul, as Microsoft was larger by then.
As for you comment about "if there was no Microsofft.." You might have a point, except a vacuum cannot sustain itself. There would have been another company, another "prince," another text editor. IBM was talking to many people. If Mr. Gates had been shot, would we have been using CP/M 80 for the past decade? What about the fellow who originally wrote DOS -- would he have become the prince? Microsoft did help, but then anyone could've stepped in as the vacuum would've been filled eventually. And Linus could've just as easily edited the bootstrap code in WordPerfect
"Gates truly is a prince. Do you really want to defy the prince?"
I'd at least want him to sign a Magnacarta, forbidding him from bundling that fscking IE.. It's a bit late, though, I've already jumped ship to Linux
---
A couple of points I'd like to make:
:-) The K.I.S.S. principle applies doubly to security. Keeping track of more possible permutations of security aside, MS is not targetting this enchanced security model at people who understand it -- "Learn Windows NT in 21 Days" has become the rule of the day, which means it's wasted and (more often than not) leads to more problems than it solves.
"NT uses security throughout the system on objects. It's then way more flexible to set security flags, without the necessity to open up the system because a certain daemon needs root access, for example."
1) Linux supports stuff like this via POSIX.1e, which allows you to flexibly drop what you don't need (super user wise). An example is ProFTPD, which has mod_linuxprivs. When it's used, ProFTPD loses all super user abilities, except for the binding to ports lower than 1024 one.
2) More complex does not mean better. During WWII, German artillery had 49 moving parts and could strike more accurately, whereas American artillery only had 9 movings parts -- it's only feature was it broke less
"MS fixes security leaks within 24 hours most of the time. Arguing it takes ages to get a fix are therefor unfounded."
It doesn't take ages to get a fix.. It just takes ages for them to post it on their website. They do really have a long latency time between a patch, and a posted patch.
"IE holes are a problem, but who surfs the net on a production server. "
Except that IE is now integrated into many other applications that don't need it (I've tried NT 5, and I really hate the grey-child-like Notepad common dialogs which huge "My Network Friends" buttons, and webenabling).. When you take an insecure code base, and cram it everywhere to stop people from ripping it out, you compromise a lot more than your morals. Then you have the marketdroid angle -- NT 5 Work^H^H^H^H Professional (where's the non-professional?) is targetted at those people who like saying they're using the "professional" version. I betcha they surf the web lots.. Do you want your CEO to go and get BOed because of their workstation OS choice?
"MS provides a bulkload of security documents how to implement security on your servers."
I'll have to go with Theo (de Raadt) on this one, and say ship the default config secured -- don't document what you have to do after the fact. When you have to install 500 workstations with a secure setup, it doesn't pay to have to go to each one and click on the same frickin' security wizards, over and over. There are ways around this, but I don't know why they don't ship with more things turned off, or at least with a visible off switch. I received some funny emails from my IDS when NT 5's probing of port 445 ("microsoft-ds") on the Linux firewall set it off..
NT 5 is better, but the ideas behind it are a mishmash of idealistic engineering, hopeful marketting, and sadly failed implementation. As the users on Bugtraq said, "it's getting better [with things like run as alternate user], but it still has lots to catch up on compared to Unix."
---
Yes.
Hopefully it will require the physical changing of a jumper on the motherboard + a special bootdisk to flash the translator units.
Flash rom BIOSes often don't require this, and video BIOSes and SCSI BIOSes are just as vulnerable in the real world, yet they aren't (to my knowledge) often taken advantage of by viruses or trojans in the wild. Any modern operating system restricts access to the hardware, so it'd take a bootdisk to put the machine into real mode before it would likely be able to flash.
Just a thought.
---
"Although Transmeta has a 128bit chip, they still emulate the x86 instructions, and are completely reliant on Intel setting standards."
...
:-) Besides, this has never posed a problem for AMD.. Being first to market doesn't always mean being best to market (K7 vs PIII).
I addressed this in another thread. So what if Intel decides night is day and white is black? It will only affect their instruction sets. If Intel goes and reverses the order of the argument bytes to the mov instruction, all they hurt are themselves. AMD and Transmeta both carry the x86 ISA torch along side Intel. They'd have to resort to another method to beat them, which leads
"Suppose Intel doesn't want to let Transmeta in on a prerelease stepping of the Merced chip?"
Intel has said before that the Merced is a 64-bit VLIW chip with a "powerful" core. In fact, they set the pricing point to be around 5 to 6 figures. I really don't think that'll clash with a low-end designed for embeded marlet processor, which uses a different simplified 128-bit VLIW core. The ol' x86 ISA doesn't get a look in anymore
---
"Why can't the software morphing layer morph your old code to the new code base?"
That's what is does do, at runtime. It doesn't morph non-running code because it's profiling to find the best performance/power usage ratio.
---
"Penultimate is not just a fancy way of saying ultimate. It means second-to-last."
;-)
Would you, in this day and age, ask if it ran Quake first?
I'd first ask if it ran Quake 3: Arena, then Unreal Tournement, etc, on down the list.. Until we hit Quake. After Quake, I'd ask if it ran Doom. So, it really is second to last
[Being flamed by you is nifty, kinda like that 48 hour period where I read your all of website]
---
"since it is maintaining compatability with x86 instruction sets, it will always follow Intel's lead (and require Intel to continue leading) mainstream chip technology."
:-)
:-)
This is like saying that because GM is making cars, they have to follow Ford's lead in how to make them. The x86 ISA is pretty much developed right now, with instructions for anything you'd care to do in silicon (or emulation). Since Intel has said that their next proc is VLIW, it looks like TransMeta's VLIW proc is leading them...
"It will never run as fast as a native x86 chip would (because it must execute extra instructions). Of course, being smaller and independent to the hardware, these chips may be made significantly faster (clock-wise) than mainstream CISC/RISC chips and comparatively match performance. But not yet."
The purpose was never performance, or the masturbatory RISC/CISC debate stuff. Its purpose is to provide good performance for insanely low levels of power consumption.
"No mention was made regarding the connection to the Internet...that was just assumed to be there. But I have yet to hear about any affordable and sufficiently fast connection via mobile unit... How will they address this, or will they just leave it up to other companies to solve this general problem?"
I think you are refering to the fact that the translation units can be upgraded via software. Software which comes over the internet
"However, Linux does not have a standards-conforming browser (i.e. IE) available until Mozilla is complete. "
(sarcasm in good humour)
Christ, what've I been running? Jeez, I guess it was just Bill himself pushing a cloaked IE through my net connection onto my desktop, as I can't be running something that's not been released..
(/sarcasm in good humour)
This will make a very nice "web panel" device, like the one Cyrix promoters were pushing.. I know I'd love to replace my 486 X terminal with a wireless laptop display
---
"I thought they would focus that as a "feature", not a mainstay of their product."
It is a feature. Did you not digest any of the info about the translation unit? It can emulate any ISA you care to specify.
"I am disappointed to see the archaic and outdated x86 architecture perpetuated by what I once thought to be a high-tech company on the bleeding edge"
I am disapointed you wasted time whinning about an ISA with a firm foothold in the world. Given an OS like Linux, you can swap processors as much as you want (ie: it's a commodity), but not everyone is using Linux.. In fact, of the 400 million (or so) Windows installations out there, I'm willing to bet a fair number of them are running on a processor that runs the x86 ISA at some point. A lot of other OSes also can run on it, like BeOS, Linux, *BSD, etc. If you don't like that fact, go buy a G4 or an Alpha, and support alternative processors. Whinning about it on Slashdot is like showing up at your local video store, and whinning about how they don't stock Beta, and why VHS is so much worse than Beta..
"AXP, sparc or even MIPS has a better architecture than the x86."
*Yawn*..
---
"Too bad it sounds like they expect nothing to be written in Crusoe's native language... There must be some speed improvement that could be gained, if say, Crusoe's achieved 40% market share in the notebook market, that would make it worthwhile for developers to create Crusoe ports."
I can't believe the number of navel gazing, performance lovers who keep saying this (or maybe I can, it's the same crowd that crows about K7 native RISC stuff).
My reply to that line of thought (the tin god of performance over all else):
"If you want performance, don't use userland apps -- they use bloated things like Java, and C++. Implement it in kernel space. Oh, and don't use C, use ASM. C has too much overhead. If you really want space, just write the specific task you want into the boot sector the floppy or HD. Of course, since it's just one task, you can dump uneeded things like interface libraries or a BIOS...."
And the reason why:
You lose flexibility when you remove the translator:
1) You now must recompile all apps.
2) You can't fix the any erratum in software any more
3) You are stuck with that VLIW core, instead of having a core you can extend up the ying-yang.
4) You can't profile the program running as it runs, and get speed boosts or power consumption benefits anymore.
The purpose is not performance. You might get hard thinking about a 1Ghz K7, but the fact is that the ram, HD, bus speed, and other parts of the computer are no where near the 1Ghz line. You're getting increasingly less of a return as you go up the Mhz ladder. The purpose of the Cursoe is flexibility. Now you have a 400Mhz proc which can emulate any other proc around a modular core, and it can profile apps, and it can live without a fan.. It is the perfect processor for embeded things like smart houses, and it does make the Palm's Dragon Ball look anemic in terms of performance -- you should like that part. The best thing is, I can also run it on a desktop with the "slow" peripherals, and it's still bitchying fast, and now allows software overclocking (as power consumption is taken care of). So even if they aren't targetting it for it, it also has the potential to be the fast thing running on electrons -- and that's because it is flexible, not performance oriented.
---
" Will it run Quake????? "
Ahh, the penultimate question of the ages -- will it run Quake.
Itchy reply finger, meet my itchy trigger finger..
Even with the site and 'cast asside, this is a laptop processor. Nothing says Quake can't run on a laptop, unless the laptop is an iBook or something. But the Cursoe proc emulates x86 ISA... So the answer is a simple 0x44 0x75 0x68..
Thanks for your time.
---
The N64's ram is expandible, and the raw processing power of the beast is not to be toyed with (consider its cost). Ever opened up the beast and played with the memory expansion card? (I have)..
Use an ISA or PCI card that connects to the plugin, and you can use your PC's ram and HD space as memory for the thing, as the design allows the cartidges (or, in this case, computer) to contain things like expansion ram, and extra processors. You may see it as limited, but it is very expenadible, and hackable.
---
"VERY low power consumption, somewhere around 1 watt during normal use. Less than a few milliwatts for "standby" mode. You can leave this thing on for weeks without difficulty. On a battery."
:-)
Not if you're cracking RC5-64
Now I can crack on my N64, too! Bwuhahaha...
---
"It's the code-morphing that makes it compatible right? Or is there some deeper compatibility at the hardware level?"
:-) This is the reprogrammible CPU we've all secretly lusted after... And because its core is VLIW, I hope we can leave behind those "[R|C]ISC is better" flamewars (which were really pathetic). The VLIW core is also very much simpler in design and cleaner (asthetically speaking) than either CISC or RISC. This is why the chip can be so cheap for the speeds they get, why it's so cool (pun), and why it uses so little power (more so inconjuntion with their translator).
Unlike the PIII or K7, which have special microhardware to translate 32-bit x86 ISA to the 32-bit RISC internal cores, the Crusoe uses a hybrid hardware/software module (patenteded, et all) that translates the 32-bit x86 ISA into 128-bit VLIW core. The fact it's in software allows them to apply RAD techniques to their translation code, which is a big win, allows them to reconfigure the hardware based on the programs running for optimal power consumption, and allows software overclocking
"Is there any reason to believe that applications written natively for this would be able to avoid the code-morphing layer and run even faster?"
Nope. Unlike the K7 and PIII, the translation is important to the process. For performance, they likely have the translator units running at a fast enough speed that the VLIW core is kept as full as if it didn't have a translator unit. And without the translator unit, you'd have to spend a few more man years designing a new BIOS, chipset, etc, that understand VLIW, as well as a new instruction fetching unit. It's easier to support the x86 ISA (which everyone supports), and stick with the design they have now. Besides, as they have pointed out, the purpose is to have a reliable low power CPU, not an "oh my god, I came it was so fast!" processor. This is best accomplished with a smart translator that is software reconfigurable around a simple VLIW core.
This doesn't stop the idea of a very high performance VLIW core desktop machine, which is what Intel is lusting after with its Merced. Luckily, the Cursoe seems a lower-level version of the Merced, which should stop any Intel strangehold on the VLIW market. And when AMD extends the x86 ISA with 64-bit instructions, your Cursusoe from the ol' year 2000 will be able to handle it. Flexbile; extensible; cheap -- I like it.
---
"I don't support trademark enforcement on domain names. If this was Microsoft making people stop the selling, all the slashdot crowd would be up in arms."
If Microsoft didn't defend their trademark, they'd lose it. Same goes for Linus, and anyone else. I support Microsoft in keeping their trademarks under their roof, and support any normal business activity. I don't support the way they break the law, but don't confuse that with rampant zealotry..
---
I'm sure a lot of us realised that, yes, these are the foul scum known as domain squatters. As well as the fact that the "nominal fee" listed on the page is a fee the domain squatters get. Linus is just trying to make sure they don't sell to every Tom, Dick, and IPO Jane out there.
This gets lost in the, "domains, Linus, lawyers -- oh my!" keyword stream of thought, which leads to rantings of hypocrisy.
---
Linus is forcing the squatters to not sell the domains. He owned the trademark first, and so he decides. This is a good thing, I think, as the squatters are just trying to profiteer on Linux(r)'s good name ;-)
Etoy had their domain first, and Etoys grabbed their "eToys.com" trademark after, so the prior art bit kicks in. I'm sure if those squatters had bought the name before Linus held the trademark (say, in 1995), they'd be well within their rights to continue to sell them.
Similar, but not same situations..
---
IMO it would set a dangerous precedent if Linus started wielding the trademark like a clue-by-four on any company that looked to make money from semi-legitimate (in the case of LinuxOne), and legitimate (in the case of Slackware, et all) businesses relating to Linux. The let them make their mistakes on their own, and let people realise that there are shady people out there.
:-)
It's a bit different when dealing with domain squatters, who are pretty close to spammers.. MO, of course
---
You're oversimplifying the situation.
Etoys who registered their trademark after Etoy existed is clearly in favour of Etoy.
SeriousDomains, a cyber-squatting group that buys domains speculatively and auctions them off to the highest bidder, bought these domaisn after Linus received the trademark. It's his decision on how they use it, and he's chosen to not let them make money from squatting.
Do you see the difference between a big company bullying someone who was already there, and someone who owned the trademark stopping domain squatting/auctioning which is likely a direct result of the recent $$$ IPOs?
---