Also, for some older software, releasing the binary might BE releasing the source code. If the authors of the program wrote machine language, (not really that much of a stretch) there isn't too much more they could release.
What I demonstrated was a special package that Red Hat provides that includes a DB of all possible packages from the distribution. Any query you can do for the installed RPM's you can do for any RPM in the rpmdb db.
So, assuming the RPM that contained the file is part of the db (everything on the main disc's, but not including powertools), you can do something like:
The first problem you describe essentially requires that you have an RPM or dpkg database that is prepopulated with all the information from all packages out there in "packageland."
Note quite "all packages out there in packageland", but all packages in your local Red Hat install:
[dougk@chief dougk]$ rpm -ql rpmdb-redhat /usr/lib/rpmdb/i386-redhat-linux/redhat /usr/lib/rpmdb/i386-redhat-linux/redhat/Basenames /usr/lib/rpmdb/i386-redhat-linux/redhat/Conflictna me /usr/lib/rpmdb/i386-redhat-linux/redhat/Group /usr/lib/rpmdb/i386-redhat-linux/redhat/Name /usr/lib/rpmdb/i386-redhat-linux/redhat/Packages /usr/lib/rpmdb/i386-redhat-linux/redhat/Providenam e /usr/lib/rpmdb/i386-redhat-linux/redhat/Requirenam e /usr/lib/rpmdb/i386-redhat-linux/redhat/Triggernam e
You know, I thought 2.4 came out just last week. If MS were to release an OS upgrade, then, a week or two later, released a patch/hotfix/etc., there would be all sorts of discussion about how they never release the good stuff, how evil it is, etc.
When the open source community does it, they speak so highly about being able to react to bugs. It is a Good Thing.
The analogy would be better if you were talking about a Red Hat/Mandrake/Suse/... release updated the kernel packages a week after the release. Distribution makers do the QA and provide the "known good" builds.
The "hey, we've changed the kernel, and think its better now?" phase we are in? Internally, Microsoft does it too.
Who gets to be the Certificate Authority? Are they going to charge as much as current commercial CAs do to verify your identity?
Key management is a big issue, check. I suspect that Network Solution(TM) (A Verisign(TM) company) would be happy to step in as a CA, ("We sold you your domain, now lets sign your key"), at which point I assume they would charge as much for that service as they do for signing your SSL key.
Currently I do not believe that there is a key-management solution in place for Secure DNS, leaving it in the same "exchange key information out-of-band" situation as PGP.
The other day an ISP released bad DNS tables whch sent yahoo.com and microsoft.com to themself, I think the OP thought that's what this story was about.
Correct. Sorry about the misplaced rant. That said, SecureDNS is still a good thing.
There is a point to this story. It points out how vulnerable DNS still is to cache poisoning. One tiny human mistake and a significant portion of the net can't get to yahoo or microsoft. See your local friendly hacker to find out how to do this deliberately.
SecureDNS (available in bind 9) allows you to sign your zone, so this kind of DNS cache poisoning can not happen. Lets roll it out and use it sooner rather than later.
It will probally be 3.0, if 1.2->2.0 is any indication...
Also, in the Linus interview linked earlier, he mentions that its premature to be talking about 2.5/3.0, indicating that the next release will likely be 3.0, and thus not really a part of the newer/quicker kernel series.
You have all of the code to PGP (or GPG). You can reverse engineer it all you want. Are you able to easily change a digitally signed message and still have the digital signature check out?
No, because I don't have the Key. In the case of a trusted client, the client has the key. Since I know the client has the key, and I have the client, I will eventually get the key. Game over, thanks for playing, I'm now the client.
If the client doesn't have a key, how do you know to trust it?
Oh, let us pray at the altar of Crypto, and we will all be saved. No need to actually try and understand anything....
By my count (2:50 am EST) from unreliable sources, Browne has 338181 votes. That's not what I was hoping for, but its not as bad as I feared.
However, 32768 of those were from Georgia.
Especially given some of the technical nature of Browne's base, does that strike anyone else as one heck of a coincidence?
That and 6% interest on your checking account never hurt either. (introductory deal until September IIRC).
Regarding passwords: I created a totally random gibberish password for my SFNB account and memorized it. I was quite upset when they forced me to change it.
So I changed it to something stupid then went in and changed it right back to the secure one. I'll probally do that again next time, and then come up with a new random gibberish password just from paranoia.
For set top boxes, and consumer Linux installations, windowing can be provided by KDE, or any other Window Manager that is ported to QT.
That's a little harder than it seems. kwm (the KDE window manager) has communicate fairly tightly with the X server. You can't write a window manager purely in terms of the functionality QT provides, you have to speak Xlib.
For there to be an Embedded QT window manager, QT would have to add a significant chunk of functionality beyond what would be required to draw widgets into a framebuffer.
Berlin attempts to replace the X server. GCI attempts to replace how graphical programs access the hardware. As I understand it, Embedded QT attempts to provide a widget set for the hardware.
Berlin might be implimented in terms of Embedded QT, which might be implimented on top of GCI. Well, not really, but I hope that got the idea across.
Grab the source for glib, gtk+ and gnome-libs and re-compile with "-O2 -finline-functions -mxyz"
I don't know how well Gnome responds to this, but KDE sometimes gets good results from being compiled with "-Os". "-Os" tells the compilier to compile for small size. This may cause the code to run slower, or if you are memory limited the much smaller footprint may actually cause it to run faster.
Nice list, but you are comparing apples to oranges without pointing out the differences:
SSH - Encrypted the telnet session. Supports but does not require better authetication, but does not provide a central authority.
Kerberos - Provides centralized authentication. I believe your connection is still vulnerable to sniffing, but could be wrong.
IPSec - Provides an Point-to-Point encrypted network link. Where SSH just provides a single TCP/IP stream, IPSec can provide a whole interface. Authentication options for IPSec vary.
Services and clients of services have been split out into different packages. For example, there is now a telnet package and a telnet-server package.
gzip has a 586-optimized version, and Mesa has a 686 optimized version.
The kernel is 2.2.15. I don't know what patches are included but knowing redhat probally quite a few.
The compilier is egcs-1.1.2. Rawhide was using gcc-2.95, so I'm confused.
The start of KDE-2 packages are there, but only the libraries basically. In the rawhide release the kfm defaulted to a Windows98 style web-explorer view. I don't know if the RH6.2 kde packages also do that.
XFree86 is up to version 3.3.6 from 3.3.2
Fvwm has been dropped. Fvwm2 is still included for those who want to avoid the Desktop Environments.
gnome is at 1.0.55. I have no idea how much has changed there.
The multi-language HOWTO's are missing from the beta. They are in rawhide, so maybe they will be in the release. Also missing from the beta but in rawhide are the Network Administrators Guide, and the System Administrators Guide.
NFS is still done in userspace. Rawhide has the knfs tools, but they did not make the trip to the beta.
Anybody else notice that the comment by the "konstant" guy is scored to 2 without an "sum of moderation" remarks attached to the post?
Is it possible that "konstant", a who-knows employee, has the ability to score himself up to 2 without moderation?
Or is my browser somehow dropping the information?
Ok, seriously: I suspect that he got to 4 the same way you got to 2, just more of it. Wasn't it Bruce that one had so much karma he posted at 5 by default?
Slashdot Mirror
Also, for some older software, releasing the binary might BE releasing the source code. If the authors of the program wrote machine language, (not really that much of a stretch) there isn't too much more they could release.
I love cheap political shots.
(bit 19 is "CAP_SYS_PTRACE", 429444307 = 0xFFFFFFFF - (1<<19) )
Others?
Just remember that "closed to the public" binaries might not be "closed to the government (or other rich organization)" binaries.
Honda S2000 - 240HP.
Nissan Maxima - 255 hp.
Honda S2000 - 2810 lbs.
Nissan Maxima - 3224 lbs.
One of these cars is faster than the other, and it ain't the one with more horsepower.
And your favorite desktop environment might contain a hot-key sequence to automatically invoke it. (KDE uses Ctrl-Alt-Escape).
- Kill cron. That's a write to
/var every minute
- mount everything with the "noatime" flag (this may break your "new mail" checks)
You may also want to look at your log files to see what else you need to kill.Er, brain fade. "The backend to access is based off of Sybase." Sorry bout that...
Ok, seriously... Why? The backend to access is based of of Sequel. Its the good part. I have no idea why you would want to replace it with MySQL.
So, assuming the RPM that contained the file is part of the db (everything on the main disc's, but not including powertools), you can do something like:
rpm --dbpath -qf /path/tofile
and find out that package "foo" contains it.
Note quite "all packages out there in packageland", but all packages in your local Red Hat install:
[dougk@chief dougk]$ rpm -ql rpmdb-redhat
/usr/lib/rpmdb/i386-redhat-linux/redhat
/usr/lib/rpmdb/i386-redhat-linux/redhat/Basenames
/usr/lib/rpmdb/i386-redhat-linux/redhat/Conflictna me
/usr/lib/rpmdb/i386-redhat-linux/redhat/Group
/usr/lib/rpmdb/i386-redhat-linux/redhat/Name
/usr/lib/rpmdb/i386-redhat-linux/redhat/Packages
/usr/lib/rpmdb/i386-redhat-linux/redhat/Providenam e
/usr/lib/rpmdb/i386-redhat-linux/redhat/Requirenam e
/usr/lib/rpmdb/i386-redhat-linux/redhat/Triggernam e
/usr/lib/rpmdb/i386-redhat-linux/redhat -q --whatprovides libesd.so
[dougk@chief dougk]$ rpm --dbpath
vorbis-1.0beta3.20010206-2
The "hey, we've changed the kernel, and think its better now?" phase we are in? Internally, Microsoft does it too.
Key management is a big issue, check. I suspect that Network Solution(TM) (A Verisign(TM) company) would be happy to step in as a CA, ("We sold you your domain, now lets sign your key"), at which point I assume they would charge as much for that service as they do for signing your SSL key.
Currently I do not believe that there is a key-management solution in place for Secure DNS, leaving it in the same "exchange key information out-of-band" situation as PGP.
SecureDNS (available in bind 9) allows you to sign your zone, so this kind of DNS cache poisoning can not happen. Lets roll it out and use it sooner rather than later.
No, because I don't have the Key. In the case of a trusted client, the client has the key. Since I know the client has the key, and I have the client, I will eventually get the key. Game over, thanks for playing, I'm now the client.
If the client doesn't have a key, how do you know to trust it?
Oh, let us pray at the altar of Crypto, and we will all be saved. No need to actually try and understand anything....
However, 32768 of those were from Georgia. Especially given some of the technical nature of Browne's base, does that strike anyone else as one heck of a coincidence?
Hawke
Regarding passwords: I created a totally random gibberish password for my SFNB account and memorized it. I was quite upset when they forced me to change it.
So I changed it to something stupid then went in and changed it right back to the secure one. I'll probally do that again next time, and then come up with a new random gibberish password just from paranoia.
That's a little harder than it seems. kwm (the KDE window manager) has communicate fairly tightly with the X server. You can't write a window manager purely in terms of the functionality QT provides, you have to speak Xlib.
For there to be an Embedded QT window manager, QT would have to add a significant chunk of functionality beyond what would be required to draw widgets into a framebuffer.
Berlin might be implimented in terms of Embedded QT, which might be implimented on top of GCI. Well, not really, but I hope that got the idea across.
I don't know how well Gnome responds to this, but KDE sometimes gets good results from being compiled with "-Os".
"-Os" tells the compilier to compile for small size. This may cause the code to run slower, or if you are memory limited the much smaller footprint may actually cause it to run faster.
gzip has a 586-optimized version, and Mesa has a 686 optimized version.
The kernel is 2.2.15. I don't know what patches are included but knowing redhat probally quite a few.
The compilier is egcs-1.1.2. Rawhide was using gcc-2.95, so I'm confused.
The start of KDE-2 packages are there, but only the libraries basically. In the rawhide release the kfm defaulted to a Windows98 style web-explorer view. I don't know if the RH6.2 kde packages also do that.
XFree86 is up to version 3.3.6 from 3.3.2
Fvwm has been dropped. Fvwm2 is still included for those who want to avoid the Desktop Environments.
gnome is at 1.0.55. I have no idea how much has changed there.
The multi-language HOWTO's are missing from the beta. They are in rawhide, so maybe they will be in the release. Also missing from the beta but in rawhide are the Network Administrators Guide, and the System Administrators Guide.
NFS is still done in userspace. Rawhide has the knfs tools, but they did not make the trip to the beta.