Did it have any specifics? Did it explain how ordinary stable elements decome fissionable through micrwaving them? Why did it not get reported widely? Did you buy that newspaper, or are you just quoting from memory?
I know, even tried it with a friend (though without succes (we did not have all the pieces, so we improvised) (IIRC it was also rather late, and we were quite possibly drunk, or otherwise less than 100% up for the task...)).
I fail to see how you can cause nuclear fission without fissionable material. While microwaving is commonly termed "nuking", microwaves are just radiowaves, in the same band as WiFi devices and such, and while metal might act like an antenna and cause electric discharges, I can't see how you would get fission.
Re:Problem not entirely RPM's fault
on
Is RPM Doomed?
·
· Score: 1
Ohh... if the filesystem is what you want standardised, check the Filesystem Hierarchy Standard. It is quite specific in what goes where.
Re:Problem not entirely RPM's fault
on
Is RPM Doomed?
·
· Score: 1
Re:Dude, get with the program
on
Is RPM Doomed?
·
· Score: 1
True, but if I was on cable that was still two maybe three mp3s more, without going over the cap;-)
Re:Binary Distros Are Dead
on
Is RPM Doomed?
·
· Score: 1
As for you statement about never going back, ha. I tried Sourcer before it broke up and about half way through the compile it didn't resolve some dependecy for the compile right and died. I went right back to RedHat outside of VMware.
Did you try asking for help? While it does happen from time to time that a missing dependency slips by, it is my experience that it is fixed very fast, some times before you can even ask for help. And the error may even have been in the actual source. So had you reported it you may even had helped the author fix a bug in his latest version... (assuming you gave up right there). And god forbid you should figure out the error yourself (it might not be hard) and help the community or the author, whoever made the mistake.
That is the way open source/free software works, people help eachother, instead of running away at the first sign of trouble. Think of where the linux kernel would be otherwise (hint: maybe on an old 386 in Linus' home (not knocking the man, but help from others made this sucker big and useful)).
Re:Just got ADSL, Just had a nightmare with packag
on
Is RPM Doomed?
·
· Score: 1
Well, for a lot of stuff the only safe way to disable, or enable, dependencies is in the configure phase of building. If the app was build to expect a library, its behavior without is absolutely not garantied to be the same as if it was never build for it.
Re:Gentoo is a giant step, too long for mere morta
on
Is RPM Doomed?
·
· Score: 1
In my experience both Red Hat and SuSE are terribly difficult to install without X and all kinds of stuff. Really annoying when all you need is kernel, shell, ssh and enough to make that run.
While a source based distro means you need gcc, bin-utils and friends, you can get a long way without X. And if need be stuff like gcc can be installed in a custom location, possibly mounted on a spare drive/partition, which can be nuked after install (simplified I know... You need libraries or you must make things static, believe me, been there, done that...).
The only thing you need binary distributions for are boot-strapping. And for that you need littele more than the build environment.
Re:Speaking of compiling...
on
Is RPM Doomed?
·
· Score: 1
Unless the author of the package made a serius error, the package should install cleanly (if the machine does not fail for reasons outside his control) once the make part is over. That why you do
./configure your options here
make && make install
If the build fails you check why, fix it and make again, posibly after configuring again.
Having used varius types of source based linux for a year now, I have never had a build problem, where this didn't hold.
Ohh... And the make clean and make distclean are for cleaning the build directory. Only variants of make install and make uninstall should do stuff outside the build directory (and hence is the only part that needs to be run as root, for all you paranoid people out there).
Well, having used Source Mage GNU Linux(which used to be Sorcerer GNU Linux) since the middle of febuary, I would like to comment on your claim that compiling from source makes the distro unstable.
While there have been a few bumps, the number of upgrades that have gone of without issues is simply staggering. And if you depend on a package, you can "hold" it (essentially disabling automatic upgrades, on a package by package basis), or if an upgrade goes sour, you can roll-back to a working version. And the upgrades are totally opt-in, you could keep the install excatly like the day you first did it.
Currently the distro is transitioning to KDE 3, GNOME 2 and GCC 3.1, and all of it is happening in an orderly fashion, with each package being tested and the upgrade keept out of the grimoire (package system) until it is ready. And even then there are two slower moving grimoires, "testing" and "stable", which will not get the upgrades, till they have been in use for some time.
And I would just like to add that it ROCKS! And it haven't even reached the point where the crew are willing to call it 1.0.
How many files in/etc are actually essential at bootup. I know that stuff like inittab, passwd and shadow are important, and can seriously fuck up your boot. But beyond those, what files actually need to be there? Stuff like the init files, fstab and server-config files might cause your machine to be less than perfect on boot-up, but most of it should be fixable, even without a reboot (restart service etc.).
The image that is compressed is just a bitmap, but besides the compressed bitmap the jpeg file also contains headers with important information about the image. It would of cause be in this (uncompressed) part of the file any virus code would live. Or it could be made to _look_ like compressed bits of image. But why on earth should the virus be planted in the image _before_ it is compressed???
While you are right that Anti-virus software is a steady stream of income, I would like to comment on your alternative.
While it is true that certain actions may indicate a virus attack, it is very hard to rule out programs that are supposed to act like that (e.g. compilers).
Also your idea of a "Safe Zone", while good, is flawed. If it was implemented, what would prevent the virus from waiting to do anything? This approach would only work against viruses that go right for the kill, not to mention that for the "Safe Zone" to be safe it would effectively be impossible to use the program for real, while it was running in the "Safe Zone", so the user would have to "test drive" programs. How often would you do that? Would everyone?
By reading the rest of the comment you would have found that the poster argues for open file formats, as an issue seperate from applications.
Imho that is a interesting point of view, since the closed file format is a very powerfull force, without which many applicastions could not maintain their dominant market share.
I strongly suspect the XFS in question is the X Font Server, since it is highly unlikely that the file system has any bearing on a crash caused by font settings.
How would having milk help him slay the dragon? Wouldn't it be in the way? Or do you know something about dragon anatomy (besides them being big and kind of flame-breathing)?
Usage: configure [options] [host] Options: [defaults in brackets after descriptions] Configuration: ...
--enable-calendar Enable building of the calendar client ...
This is from the 1.0 source-tree. So if you want it, calendar is in 1.0 (Note: I haven't tested it, and you need to install a special libical, but it's there).
You are assuming that the server should connect to other servers. That may be true for a limited number of services (webserver to db-server or such), but in general there is no reason to trust a host to do anything other than what it is supposed to do. So just don't assume that the servers will remain under your control, put them on a DMZ and allow only the connections from them that are truely needed.
Oh, and if you take the (great) advice of a lot of several other posters and run cvs (or anything else) over ssh, thake a look at keychain from Gentoo Linux. It's a nice wrapper around ssh-agent, minimizing the number of times you have to type your password.
If you use cvs for this kind of thing, cron-jobs can make things a lot smoother when dealing with program settings and the like (I use it for stuff like my bookmarks). Just make the cron-job sync all your machines to a central repository at short intervals. That way you should be able to maintain consistent files in all machines, and if something goes wrong you can roll back to an earlier version.
Add a bit of clever scripting, and you might also handle whole dirs automagically (cvs works on individual files).
One word of caution: Be careful with binary files, and programs that restructure files, since thats not what cvs is made for (you can set files as binary though).
Slashdot Mirror
Did it have any specifics? Did it explain how ordinary stable elements decome fissionable through micrwaving them? Why did it not get reported widely? Did you buy that newspaper, or are you just quoting from memory?
I know, even tried it with a friend (though without succes (we did not have all the pieces, so we improvised) (IIRC it was also rather late, and we were quite possibly drunk, or otherwise less than 100% up for the task...)).
Neverthe less it is a nice experiment.
Would you care to back up that claim?
I fail to see how you can cause nuclear fission without fissionable material. While microwaving is commonly termed "nuking", microwaves are just radiowaves, in the same band as WiFi devices and such, and while metal might act like an antenna and cause electric discharges, I can't see how you would get fission.
Ohh... if the filesystem is what you want standardised, check the Filesystem Hierarchy Standard. It is quite specific in what goes where.
And the Linux Standards Base.
True, but if I was on cable that was still two maybe three mp3s more, without going over the cap ;-)
Did you try asking for help? While it does happen from time to time that a missing dependency slips by, it is my experience that it is fixed very fast, some times before you can even ask for help. And the error may even have been in the actual source. So had you reported it you may even had helped the author fix a bug in his latest version... (assuming you gave up right there). And god forbid you should figure out the error yourself (it might not be hard) and help the community or the author, whoever made the mistake.
That is the way open source/free software works, people help eachother, instead of running away at the first sign of trouble. Think of where the linux kernel would be otherwise (hint: maybe on an old 386 in Linus' home (not knocking the man, but help from others made this sucker big and useful)).
Well, for a lot of stuff the only safe way to disable, or enable, dependencies is in the configure phase of building. If the app was build to expect a library, its behavior without is absolutely not garantied to be the same as if it was never build for it.
In my experience both Red Hat and SuSE are terribly difficult to install without X and all kinds of stuff. Really annoying when all you need is kernel, shell, ssh and enough to make that run.
While a source based distro means you need gcc, bin-utils and friends, you can get a long way without X. And if need be stuff like gcc can be installed in a custom location, possibly mounted on a spare drive/partition, which can be nuked after install (simplified I know... You need libraries or you must make things static, believe me, been there, done that...).
The only thing you need binary distributions for are boot-strapping. And for that you need littele more than the build environment.
Unless the author of the package made a serius error, the package should install cleanly (if the machine does not fail for reasons outside his control) once the make part is over. That why you do
./configure your options here
make && make install
If the build fails you check why, fix it and make again, posibly after configuring again.
Having used varius types of source based linux for a year now, I have never had a build problem, where this didn't hold.
Ohh... And the make clean and make distclean are for cleaning the build directory. Only variants of make install and make uninstall should do stuff outside the build directory (and hence is the only part that needs to be run as root, for all you paranoid people out there).
Well, having used Source Mage GNU Linux(which used to be Sorcerer GNU Linux) since the middle of febuary, I would like to comment on your claim that compiling from source makes the distro unstable.
While there have been a few bumps, the number of upgrades that have gone of without issues is simply staggering. And if you depend on a package, you can "hold" it (essentially disabling automatic upgrades, on a package by package basis), or if an upgrade goes sour, you can roll-back to a working version. And the upgrades are totally opt-in, you could keep the install excatly like the day you first did it.
Currently the distro is transitioning to KDE 3, GNOME 2 and GCC 3.1, and all of it is happening in an orderly fashion, with each package being tested and the upgrade keept out of the grimoire (package system) until it is ready. And even then there are two slower moving grimoires, "testing" and "stable", which will not get the upgrades, till they have been in use for some time.
And I would just like to add that it ROCKS! And it haven't even reached the point where the crew are willing to call it 1.0.
How many files in /etc are actually essential at bootup. I know that stuff like inittab, passwd and shadow are important, and can seriously fuck up your boot. But beyond those, what files actually need to be there? Stuff like the init files, fstab and server-config files might cause your machine to be less than perfect on boot-up, but most of it should be fixable, even without a reboot (restart service etc.).
/etc is a great idea.
But either way, backups of
The image that is compressed is just a bitmap, but besides the compressed bitmap the jpeg file also contains headers with important information about the image. It would of cause be in this (uncompressed) part of the file any virus code would live. Or it could be made to _look_ like compressed bits of image. But why on earth should the virus be planted in the image _before_ it is compressed???
While you are right that Anti-virus software is a steady stream of income, I would like to comment on your alternative.
While it is true that certain actions may indicate a virus attack, it is very hard to rule out programs that are supposed to act like that (e.g. compilers).
Also your idea of a "Safe Zone", while good, is flawed. If it was implemented, what would prevent the virus from waiting to do anything? This approach would only work against viruses that go right for the kill, not to mention that for the "Safe Zone" to be safe it would effectively be impossible to use the program for real, while it was running in the "Safe Zone", so the user would have to "test drive" programs. How often would you do that? Would everyone?
By reading the rest of the comment you would have found that the poster argues for open file formats, as an issue seperate from applications.
Imho that is a interesting point of view, since the closed file format is a very powerfull force, without which many applicastions could not maintain their dominant market share.
I strongly suspect the XFS in question is the X Font Server, since it is highly unlikely that the file system has any bearing on a crash caused by font settings.
How would having milk help him slay the dragon? Wouldn't it be in the way? Or do you know something about dragon anatomy (besides them being big and kind of flame-breathing)?
(emphasis mine)
Well, which TWO letters of "Peoples Optimised Republic of Nyland" and "African Democracy Under Leaders of Trouble" would you like for a ccTLD?
~/mozilla#
Usage: configure [options] [host]
Options: [defaults in brackets after descriptions]
Configuration:
...
--enable-calendar Enable building of the calendar client
...
This is from the 1.0 source-tree. So if you want it, calendar is in 1.0 (Note: I haven't tested it, and you need to install a special libical, but it's there).
You are assuming that the server should connect to other servers. That may be true for a limited number of services (webserver to db-server or such), but in general there is no reason to trust a host to do anything other than what it is supposed to do. So just don't assume that the servers will remain under your control, put them on a DMZ and allow only the connections from them that are truely needed.
Unless you only want to rewrite the part of the truth you didn't forget (the opposite of what you are saying), try this instead:
find / -name \*truth\* -exec rm -i {} \; -exec test \! -e {} \; -exec emacs {} \;
This way you get to rewrite everything you delete/forget. You also avoid passing the whole lot as arguments in one go.
Oh and the second line of yours doesn't parse, it lacks a trailing `.
Oh, and if you take the (great) advice of a lot of several other posters and run cvs (or anything else) over ssh, thake a look at keychain from Gentoo Linux. It's a nice wrapper around ssh-agent, minimizing the number of times you have to type your password.
If you use cvs for this kind of thing, cron-jobs can make things a lot smoother when dealing with program settings and the like (I use it for stuff like my bookmarks). Just make the cron-job sync all your machines to a central repository at short intervals. That way you should be able to maintain consistent files in all machines, and if something goes wrong you can roll back to an earlier version.
Add a bit of clever scripting, and you might also handle whole dirs automagically (cvs works on individual files).
One word of caution: Be careful with binary files, and programs that restructure files, since thats not what cvs is made for (you can set files as binary though).
Never mind, I'll just look at the raw encoded data.