Before SMS became popular, we hacked up a small e-mail reader (with festival) that would call a cellphone in case of emergency. This system was used to alert network admins whenever a router was down. The trouble ticket got mailed to a "voice mail account" and the skript called the poor guys and read them the TT summary. Well, spam could not hit that internal account, so we were safe.
This was actually very useful, but we needed a backlink: Fortunately, touch tones were a poor substitute to a keyboard, and the netadmins could send a router commands from their mobile, and have the results spoken (rather awkwardly) back.
Of course, the dream was to be able to speak the Cisco IOS incantations directly and have the program recognize them. This was never implemented though...
You need a graphics terminal that can be used by vnc
You need an API and library for clients to connect to the graphics terminal
Keeping backward compatibility of X11 clients would be highly desirable!
So we would still be left with the tasks to write a powerful graphics server as replacement for XFree86, an interface library for clients, and a legacy library to support the X11 wire protocol used by millions of X clients (some of them not necessarily open sourced).
We could argue that most X clients use toolkits rather than raw X11 calls, and that would be true. So you'll have to modify the toolkits themselves. This would still be a formidable task.
Of course I was wrong here: A simple 3-way handshake would require 3+3+3=9 months for a server 3 light months away. A simple TCP connection would require a huge sliding window, but even then, waiting for acks would take ages. Of course, astroborg would be dead long ago!
# cvsup -g -L 2/etc/cvsupfile
# cd/usr/src
# make buildworld
# make buildkernel KERNCONF=BORG
# make installkernel KERNCONF=BORG
# reboot (single user)
# make installworld
# reboot (multiuser)
Of course, cvsup would need 3+ months to connect to the nearest cvsup server 3 lightmonths away, and a make buildworld would require an additional week to complete. Results:
gmake[1] ERROR: Compile unsuccessful. re cvsup in a week.
I would like to see a completely modular, X-windows core-compatible windowing system for Linux. Want to use some of the advanced features? Add in the module, recompile, and go!
Why the need to recompile? Make all advanced features dynamically loadable modules and that's it.
Actually, most features of X11, including networking, _are_ being used a lot, especially in corporate environments. There's nothing more useful than being able to use 1 or 2 monitors (X servers) with remote applications running on them. Just because some end-users never experienced such work environment, doesn't mean that we should cripple XFree86 or even reinvent the wheel for the umpteenth time just to fit their (already covered?) needs.
With a modular environment, people would be able to extend XFree86 with backward compatibility in mind. This would be much better than a complete redesign, which didn't yet prove its worth.
Some X replacement projects were attempted, but they never reached beta. IMHO for a good reason.
Sure, it's called leak current and it means that electrons escape circuits and start littering the environment. Good that fiber optics cable don't carry electrons. Now, photon-waste would be possible, if some terrorists or barracudas cut through the fiber cables... Uh oh!
Yes, they are in the same market, and perform both more or less decently. I'm a sysadmin who was a fan of SuSE for a long time, but I switched to FreeBSD after having been hugely disappointed by SuSE's pricing policy for end users when they introduced the Euro currency in Europe. Yes, this alone is not a sufficient criterion, but it sticked, I've since then helped convert many ten-thousands of computers in enterprises to FreeBSD (both from SuSE and RH and M$). And less than 0.5% of the users and local admins thought it was a bad move and reverted back to Linux. None went back to Windows though:-)
If I really need a brand new device driver for some new off-the-shelf hardware, I'd go with SuSE, which is quite mature here. But if that device is supported by FreeBSD (which often happens after a small time lag), I quickly go back to BSD.
I'm using CURRENT since 5.1 on a regular basis, and I had very few problems with it. As far as I'm concerned, CURRENT is kind of semi-stable at the moment. Of course, every cvsup can break this, but this is not really new:)
P.S.: 5.1 is really cool, esp. on an SMP motherboard.
If I were to implement a watermarking scheme, I would add an option to gcc (and gas and ld), which would perform like this:
1. ELF sections would contain a watermark.
2. A cyrptographic checksum (SHA) will be
appended to the watermarked ELF section.
3. C initialization code would verify the
integrity of the ELF section, and refuse
to start if it were tampered with.
Of course a few additional steps need to be taken
in order to avoid circumvention of this scheme.
Now, if some dumb company or individual were to tamper with the watermark, the cryptographic checksum won't compute anymore and the startup code would refuse to load the program.
Of course, this scheme is far from perfect:
a. The startup code could be replaced by
a script/proggy which modifies ELF files.
b. Checksums need to contain a secret seed
of else they would be computable too.
But for casual tampering (of _binary_ executables), this would be more than enough.
Slashdot Mirror
Before SMS became popular, we hacked up a small e-mail reader (with festival) that would call a cellphone in case of emergency. This system was used to alert network admins whenever a router was down. The trouble ticket got mailed to a "voice mail account" and the skript called the poor guys and read them the TT summary. Well, spam could not hit that internal account, so we were safe.
This was actually very useful, but we needed a backlink: Fortunately, touch tones were a poor substitute to a keyboard, and the netadmins could send a router commands from their mobile, and have the results spoken (rather awkwardly) back.
Of course, the dream was to be able to speak the Cisco IOS incantations directly and have the program recognize them. This was never implemented though...
Good point. VNC would do the networking... but:
So we would still be left with the tasks to write a powerful graphics server as replacement for XFree86, an interface library for clients, and a legacy library to support the X11 wire protocol used by millions of X clients (some of them not necessarily open sourced).
We could argue that most X clients use toolkits rather than raw X11 calls, and that would be true. So you'll have to modify the toolkits themselves. This would still be a formidable task.
cpghost at Cordula's Web.
Don't like Don't like it? You've got the source: fix it yourself!
Yeah. kdefibrilator-0.62.1 is still alpha.
Why not modifiy kastroborg/dna.h to avoid kardiac-arrest altogether. A known vuln. was published on bugtraq some times ago. Time to tackle that one!
cpghost at Cordula's Web.
Of course I was wrong here: A simple 3-way handshake would require 3+3+3=9 months for a server 3 light months away. A simple TCP connection would require a huge sliding window, but even then, waiting for acks would take ages. Of course, astroborg would be dead long ago!
cpghost at Cordula's Web.
No problem:
# reboot
And if it still doesn't work, here's the BSD way:
# cvsup -g -L 2 /etc/cvsupfile /usr/src
# cd
# make buildworld
# make buildkernel KERNCONF=BORG
# make installkernel KERNCONF=BORG
# reboot (single user)
# make installworld
# reboot (multiuser)
Of course, cvsup would need 3+ months to connect to the nearest cvsup server 3 lightmonths away, and a make buildworld would require an additional week to complete. Results:
gmake[1] ERROR: Compile unsuccessful. re cvsup in a week.
gmake[1] ERROR: Installworld unsuccessful: target dead!
cpghost at Cordula's Web.
I would like to see a completely modular, X-windows core-compatible windowing system for Linux. Want to use some of the advanced features? Add in the module, recompile, and go!
Why the need to recompile? Make all advanced features dynamically loadable modules and that's it.
Actually, most features of X11, including networking, _are_ being used a lot, especially in corporate environments. There's nothing more useful than being able to use 1 or 2 monitors (X servers) with remote applications running on them. Just because some end-users never experienced such work environment, doesn't mean that we should cripple XFree86 or even reinvent the wheel for the umpteenth time just to fit their (already covered?) needs.
With a modular environment, people would be able to extend XFree86 with backward compatibility in mind. This would be much better than a complete redesign, which didn't yet prove its worth.
Some X replacement projects were attempted, but they never reached beta. IMHO for a good reason.
cpghost at Cordula's Web.
Or run Apache in chroot()ed environment. Or even better in a FreeBSD jail. Anyone done that? Experiences?
> Ever hear of E-waste?
Sure, it's called leak current and it means that electrons escape circuits and start littering the environment. Good that fiber optics cable don't carry electrons. Now, photon-waste would be possible, if some terrorists or barracudas cut through the fiber cables... Uh oh!
Yes, they are in the same market, and perform both more or less decently. I'm a sysadmin who was a fan of SuSE for a long time, but I switched to FreeBSD after having been hugely disappointed by SuSE's pricing policy for end users when they introduced the Euro currency in Europe. Yes, this alone is not a sufficient criterion, but it sticked, I've since then helped convert many ten-thousands of computers in enterprises to FreeBSD (both from SuSE and RH and M$). :-)
And less than 0.5% of the users and local admins thought it was a bad move and reverted back to Linux. None went back to Windows though
If I really need a brand new device driver for some new off-the-shelf hardware, I'd go with SuSE, which is quite mature here. But if that device is supported by FreeBSD (which often happens after a small time lag), I quickly go back to BSD.
This is just my personal experience. YMMV.
I'm using CURRENT since 5.1 on a regular basis, and I had very few problems with it. As far as I'm concerned, CURRENT is kind of semi-stable at the moment. Of course, every cvsup can break this, but this is not really new :)
P.S.: 5.1 is really cool, esp. on an SMP motherboard.
If I were to implement a watermarking scheme, I would add an option to gcc (and gas and ld), which would perform like this: 1. ELF sections would contain a watermark. 2. A cyrptographic checksum (SHA) will be appended to the watermarked ELF section. 3. C initialization code would verify the integrity of the ELF section, and refuse to start if it were tampered with. Of course a few additional steps need to be taken in order to avoid circumvention of this scheme. Now, if some dumb company or individual were to tamper with the watermark, the cryptographic checksum won't compute anymore and the startup code would refuse to load the program. Of course, this scheme is far from perfect: a. The startup code could be replaced by a script/proggy which modifies ELF files. b. Checksums need to contain a secret seed of else they would be computable too. But for casual tampering (of _binary_ executables), this would be more than enough.