I was fighting the usual problems with networks and came up with the
following dream to make my life easier as a network admin. Basically I
am tired of fixing things, of worrying if a hard disk will die, of
having to deal with data access, backup etc...
Anyway here it is: Basically, I suggest that (almost) all PCs in the
network be laptops with the exact same image. Furthermore, they
replicate their HD continuously!!! I am not sure of the technology to
use here, but I thought something deriving from the P-to-P technology,
some distributed file system, some database replication technology or
even freenet could be a good base. Since every laptop will contain ALL
the data for the whole network, every laptop uses hardware encryption
at the hard disk level using an external dongle/card/whatever.
Additionally, every login ALSO uses a dongle/card for access to their
account. This makes it (almost) impossible for somebody stealing a
laptop to get access to the whole data. Additionally, it makes it
(alomst) impossible for somebody to fet to other people's data. If a
system dies, you just get a new one and sync it up. However, one main
idea is that you always have EVERYTHING you need right where you are,
no matter WHERE you are. Also, there is no UPS to worry about.
Communication between PCs could be implemented using VPN/IPSec or
whatever other protected mechanism. Internet access would have to be
"sandboxed", but UNIX based OSes allow for that easily. That's the
gist of it. A lot of things can be configured in many ways, but the
whole point here is to simplify people's life.
I wanted to post it here for other people to use if they think it's a
good idea. (and also to preempt any proprietary company from saying
I posted this somewhere and somebody pointed me toward stateless linux
and it seems pretty cool and close to what I was thinking of. I'll
look smoe more into it, but does anybody see this as useful for VERY
SMALL networks? (I already got bashed by enterprise admins sneernig at
people who don't want a rack server, so if that's your intent, just
reply "me too").
It doesn't start at all for me.
I also tried:
./firefox-bin: error while loading shared libraries:
libmozjs.so: cannot open shared object file: No such file or
which of course is in the same directory -
/usr/lib64/firefox-1.1 - but that's without all the script
I am encountering some problems with my USB mouse with semi-current
kernels (kernel-2.6.12-1.1400_FC5 is affected, maybe earlier, too).
Sometimes mouse clicks are not recognized. Enabling the debug system
and listening on /sys/kernel/debug/usbmon/... shows that no USB
events are being generated for these missed clicks, either.
Some clicks are registered double, but this is far more rare.
Have there been changes to the kernel which may explain "lost"
USB events? Or is it more probable that a mechanical failure
"It doesn't matter how fast your modem is if you're being shelled by
ethnic seperatists." -- William Gibson
It seems that the behavior of /dev/random has changed recently in rawhide.
I have a machine configured to use an encrypted swap space with /dev/random as
the source for the key via the "-d /dev/random" option to cryptsetup.
Until recently the command "cryptsetup -d /dev/random create swap /dev/hda2"
completed in a reasonable amount of time. Now it will hang almost
indefinitely (I've waited for over 16 minutes). Pressing the SHIFT, CTRL, and
ALT keys repeatedly during the boot process can make cryptsetup complete in
as little as a second.
It seems to me that previous kernels used some entropy that's available during
boot (such as interrupts from the hard disk) and recent kernels have stopped
Is this a bug or a feature?
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Beginning tomorrow, hotplug events will now be handled directly by udev
The only hotplug agents left will be input (because the kernel isn't fixed
yet) and net (because that's, well, different).
Removed but not replaced were the dasd/tape s390 agents; these just created
additional device symlinks for compatibility with really really old devfs
installations; it's probably time for this compatiblity to be removed.
In the intrest of getting API's out that more reflect what we will see
in D-Bus 1.0 I am toying with the idea of upgrading FC4 to the same
version in Rawhide. This does not effect the lowlevel D-Bus libraries
except for fixing a couple of bugs. What this does is give a more
usable GLib and Python bindings.
What this also does is break apps using those bindings. GLib is a
pretty big change but then again this is the first release we thought
was good enough for mass consumption.
Python itself is changed in a number of ways but mostly when creating a
service. Clients on the bus who just fire off blocking messages should
have no changes needed. Clients who still need a mainloop will simply
have to import dbus.glib.
With FC5 a ways off I think it is more important to get wide use of
these API's as they will most likely be than to keep compatability with
the 0.33 bindings. I'm not promising API's won't change but we are now
in the mode where we are trying to keep them relitivly the same.
The purpose of this mail is to find out if there are any third party
apps that use the GLib or Python bindings that are packaged for or with
FC4 and if those developers would object to this upgrade. The real
question is would you like the pain now or later? :-) I'll put a tarball
in testing sometime this week.
I say rip the bandade, but that is just me. The GLib bindings shouldn't
have seen much use as of yet and the Python bindings are mostly used for
clients of which requires a one or twoline change when using a mainloop.
I'm not aware of any production code that uses the Python bindings as a
server. Plus with the new bindings the tutorials of fd.o
(http://dbus.freedesktop.org/doc/dbus-tutorial.html) will actually match
what is in FC-4.
John (J5) Palmieri <johnp(a)redhat.com>
>>>>> "JR" == Jon Roland writes:
JR> Jason Hecker wrote:
>> Build your own RPMs using the www.jpackage.org spec files and
>> downloading the JSE from Sun. It's a bit of a PItA (and an
>> impediment to a fluid Linux experience) but it works well and the
>> Mozilla/Firefox plugin Java runs without a hassle (though it's
>> hidden deep in a convoluted directory tree).
JR> Thanks, but I don't know how to build an rpm from a spec file yet,
JR> and I'd rather not have to learn how right now. Surely someone has
JR> done this and made an easy solution available for those of us who
JR> just want things to work.
The instructions on http://www.jpackage.org/rebuilding.php are
step-by-step, and don't require you to know much about spec files,
just how to run a few commands from the command line. It looks a bit
scary, but really it's actually very simple and the instructions don't
require you to learn about the ins-and-out of RPM packaging.
Until Sun provide either less brain-dead generic and/or
Fedora-specific RPMS, unfortunately this *is* the easiest (legal) way
to install Java in a nice Fedora-compliant way.
Third-party packagers which want to be 100% above board (including
jpackage, freshrpms etc.) can't legally redistribute the RPM and
include the Sun binaries in their packages because the user needs to
download the binaries and agree to the EULA etc.
AFAIK jpackage *would* provide straight binary RPMS this way, because
it would "just work" if they could be sure it was 100% legit, it's not
that they prefer it this way. So in answer to your question, somebody
has "done this", but they can't legally redistribute those packaged
Having said that, it might be useful if jpackage could supply a script
that did the heavy lifting, and leaving just the download itself to
the user, but that should be brought up with the jpackage people.
Just got a commit i/o error for ext-3 in kernel-2.6.12-1.1398_FC4.
Bunch of my files went wack-o and directory inodes became symlinks
to ??. Couldn't shutdown. Init said I/O error.
Reverted back to 1390, recovery worked and files/dirs back to normal. I
couldn't find any detailed logs and the kernel didn't panic. So, it
maybe a badblock on my HDD that it hit or something's screwed in the
ext3 driver in 1398.
I'm not a kernel expert, but will be willing to run any diags on it to
see if it happens again. I've noticed that CONFIG_JBD_DEBUG is not
set, so, i guess i'd have to recompile...
Anyway, has anyone else run into problems?