I guess it only deals with personal use then. I'm sure there'd be another tack that would allow Bugtraq to still use it. Time for me to go to law school.:)
I don't think that they would have a leg to stand on if Bugtraq still posted them. As long as they aren't used to generate profit, I think that reproducing them would fit under the fair use provisions in copyright law.
"enum" is an enumerated data type. It is used when data is known to be only one of a discrete, finite, small number of options. Instead of encoding them so that they correspond to numbers (hard to read/comprehend) or making them strings (slow processing) you can use an enum. For example, you need to keep a list of the members of your household, you could make an array of strings to hold them but unless you need to manipulate their names as strings, that's wasteful. You could map them to numbers (1=dad, 2=mom, 3=jane, 4=john) but that's hard to remember who is who, So, you set up an enumerated type that can take the values of dad or mom or jane or john like this:
enum (dad, mom, jane, john) family_member;
then you can do this assignment:
family_member = jane;
Also, since they are a finite, discrete list of values, C actually maps them to integers for you behind the scenes so you can use the enum variable as if it were integers. So, you could do:
for (int i=dad; i < john; i++) {
print my_name[i];
}
That's a bit easier to understand.
Anyway, long-winded, but enums are useful but not the end-all be-all of a language.:)
I take it you have never had to suffer through an NT crash that destroyed the registry so that the machine wasn't bootable. UNIX machines, with their text-based administration is great. You can wrap GUI tools around it so that it's easy to change things in X. However, when the system crashes to the point that you can't use the database tools to fix the system, there is no substitute for using a simple text editor of some sort to prevent having to reformat. I agree that the tendency to toss config files around is a bad idea. I definitely recommend a more organized approach to config files. Say, use an/etc/config (or even a/config) directory for them and each app creates a directory there with its name and version number to hold its global config stuff. That will make it still rather simple to have global config stuff in one place and also make it easy to delete the config stuff when you delete the app. Better yet, make a POSIX standard that gives you a function in sysconf() to find out what the configuration directory is. I can't tell you how appreciative I am of sed and how many times it has helped me when I have fscked my system to the point that I can't even run vi.
A program is not just a file
I agree that a program is a collection of resources and config files as well as the libraries and executables that make it up. Mac OS X has borrowed the NeXTSTEP idea of bundles which shows that this kind of think could be well used in general UNIX. However, you could put resources and stuff in the executable itself by extending the ELF format to hold it (or use ELF notes). You could even have the standard resources in the aforementioned config directory. I think that file forks are a bad idea, however.
UNIX interprocess communication sucks
I disagree here, too. Yes, having a kernel-supported RPC (similar to NT's LPC -- Local Procedure Call) would be nice, but it's not much more to that than just sending the program a message to a well-defined port and processing the reply. You didn't mention Shared Memory, Semaphores, or Message-Passing when discussing UNIX IPC. These were brought in by SYSV, not BSD, and make excellent additions to the IPC that UNIX has to offer.
This is where the beauty of OO design comes in. You take an existing object that does most of what you want, derive a new object from it that WILL STILL HAVE THE PREVIOUS INTERFACE AS A SUBSET TO ITS INTERFACE so the new object can be used in place of its parent and voila. There you have it. That is how code reuse can be useful and good.
This was a major concept I taught to a class in C++, and more use should be made of it.
I wouldn't be surprised if there is already a good amount of this going on within the BeOS since it's all in OO C++. C is harder to do OO stuff with, but since gtk+, et. al. are OO in C, it is possible.:) Go GNOME! Go Bouncing Bonobo! (yes, I remember that pre-release).
Hmmm...I hate to see a good UNIX company having trouble. Sure, it's not open source and all, but open source is not the end-all, be-all of UNIX computing. I love Linux and *BSD, et. al. but it's good to have some official commercial companies showing that you don't have to sell out to Windows.
However, that said...it's possible that this could be a good thing...all those peeps who used SCO could turn around and upgrade to Linux.:)
Actually, yes. The "Capabilities" referred to are an SGI spinoff that will allow a piece of software to temporarily take on additional capabilities and then shed them. This will allow finer-grained access control to files and also go a long way towards removing the necessity of having suid-root proggies.
I am curious...how does OpenLDAP stack up against these two other options? Will Windows2000 machines talk standard LDAP or will we be forced to use Active Directory even if we have an already existing LDAP solution?
Not quite. They would have to start providing source once they start spreading the modified Linux. If they spread machines without Linux on them, they don't have to do diddly about providing source.
Has anyone managed to get a TNT2 card working with 3D accelleration with X 3.9 by any chance? I've had no 3D accelleration under Linux since I got my Viper 770, and Nvidia isn't any help.
The key to 3D acceleration with TNT2 is the Nvidia X Server which is downloadable from their website. It's built against XFree86-3.3.5, so you'll have to have that version of XFree86 installed. They include a rather nice install script that copies the X Server and glx and GL libraries. You will also need to have Mesa installed.
Unfortunately, when I try to get automount to work with smb filesystems, I get the following error messages in/var/log/messages:
Nov 12 11:23:02 helsinki automount[10387]: attempting to mount entry/lsi-ou-server/c Nov 12 11:23:02 helsinki automount[10392]: cannot find mount method for filesystem smbfs
My automount line looks like this:
c -rw,fstype=smbfs,user=administrator,password='dele ted' "//lsi-ou-server/c$"
Thanks for your help and all the wonderful Samba work!
Too long to compile on an 8MB 386DX33? Then use your kick-a$$ machine to cross-compile the kernel for your 386 machine.:) Ah the wonders of free software.:)
That is not quite correct. The load average is the average number of processes that are eligible to run, but can't over that time period. The three time periods are 5 minutes, 10 minutes, and 15 minutes. Basically, the load average tells you the average size of the ready queue in the system over those time periods. This measure is useful to see if the system is overloaded because if the 15 minute average is quite high, then the system has had a rather large ready queue for quite some time.
I'd like to answer statements if I might, point by point.
I find the stacks of libraries clumsy...not nearly as clean as they should be IMHO.. on the gnome road...fnome sits on gtk+ sits on Xlib.. on the straight X road Motif of Athena sits on Xt sits on Xlib...etc. for all the other libraries...if it wasn't so painful to work in the core API, we would not need all these things
Have you ever looked at the low-leve Windows API? That is just as tough to work with as the Xlib API. Windows programmers don't work with the Windows API directly. They use the common widgets in WinX. commdlg.dll, et. al. are libraries built on top of the Windows API. That is what the widget set does. I have used and worked with both the Xlib API and the Windows API and they are both low-level beasts. But, they are nice, fast ways to get things done. If you want convenience, you stack libraries on top of each other.
Along with being old, comes supporting old versions of the API.. while I understand the need for this, some of the old API (which was all run through sockets) is really kludgy and takes away from the speed
I agree with this. What would be better would be to allow shared memory (I know, I know, that's SYSV IPC, BSDers) accesses for the threads in a process to communicate to the X server. However, using a local UNIX domain socket is just as good for local communication anyway and that's what X uses when you are local to the machine anyway.
Mmm.. shared memory... shared memory(now that it exists in UNIX (at least in all of the unixes I have used: Solaris, Irix, Linux, and I am pretty sure FreeBSD, OpenBSD, prob. NetBSD, maybe AIX) all have support for shared memory which is a much faster interface than older unix ipc interfaces like pipes...
UNIX has had shared memory for quite a while. It was developed as part of the System V inheritance tree, so BSD UNIX has been lacking it, though FreeBSD and others might have added it lately. As to shared memory being faster than unix domain sockets, I don't know that I agree with this. I'll have to do some tests to see if it's faster. Here's why. You have process A writing and B reading. A writes to a pipe and writes to a pipe and writes to a pipe. Not caring if B has read the data yet. As long as the pipe isn't full, A can write. With shared memory, A has to worry about filling up shared memory and delineating the messages, or if there is only a rather small space that is shared, A has to wait for B to signal that it has read the data. Here is my take on some beefs with X.
Threading. I'd like to see X get good threading support in it. I know the calls are there for XCreateThread() and friends, but I think that each thread created with XCreateThread() should get their own Xlib queue to talk to the X server. However, they should share all of the XIDs with each other. That way, you don't have to treat EVERY X call as a critical section. Each thread writes to its contact point with Xlib and reads from its private queue.
GTK+ is a great library. However, I think that the gdk layer is unneeded. gdk is basically a wrapper around Xlib that does virtually the exact same thing as the underlying Xlib call. Yes, there are some differences and for those calls it is OK. However, I think that GTK+ could be more efficient if it were written on top of Xlib instead of on top of gdk on top of Xlib.
Just my musings.:) Enjoy!
Re:The problem is more severe in Windows
on
BO2K cracked
·
· Score: 1
DOH! I know you don't have to reboot. I was half-thinking of changing network settings.:) It's still pretty da#n inconvenient to have to log out and log back in, esp. if you want to do things as yourself, too.
Re:So what's the solution?
on
BO2K cracked
·
· Score: 1
grrr... Darn interpretation of HTML. The phrase "opening a socket 1024" should read "opening a socket 1024"...
Re:So what's the solution?
on
BO2K cracked
·
· Score: 1
Properly set up group permissions and memberships can alleviate the need to log in as root most of the time. no program NEEDS to run as root unless it is opening a socket 1024 or directly accessing video hardware since there is no device file for it. Beyond that, it's all based on permissions to the files. You can set up a sysadmin group and make all administrative files in that group and make the proper people members of that group and you can access anything you need without su-ing to root. You can even manage the password file that way (though I wouldn't recommend it).
Re:The problem is more severe in Windows
on
BO2K cracked
·
· Score: 1
Ahem...unless the user is also in the Administrators or Domain Admins group. Since Windows has no DECENT su command equivalent, many Administrators put their account in the Administrators and/or Domain Admins groups to make it easier to administer their systems without a reboot.
while (!ok) { fprintf(stderr, "waiting...\n"); sleep(5); }
fprintf(stderr, "retreived data: %s\n", buf); }
Works fine under Slowlaris and Irix, but Linux doesn't get the signal. Any ideas? I'd love to believe that Linux supports Async I/O, but I need to prove it to myself first.
Cheers!
Re:you're just missing header files ...
on
Linux 2.2.8
·
· Score: 1
Better yet is to just un-rpm kernel and kernel-headers. Ignore the errors. Then, cd to/usr/src and unpack the kernel source there, mv the linux directory to one that is aptly named (linux-2.2.8, in this case), ln -s linux-2.2.28 linux, then unpack the kernel sources and then make the symlinks from/usr/include for linux and asm to/usr/src/linux/include/linux and/usr/src/linux/include/asm, respectively. Finally, go to/usr/src/linux/include and ln -s asm- asm. In my case, I use asm-i386 for the architecture-specific asm headers.
After that, NEVER use another RedHat kernel RPM.:) Just use the tar.gz's (or bz2 if you prefer them).
Slashdot Mirror
I guess it only deals with personal use then. I'm sure there'd be another tack that would allow Bugtraq to still use it. Time for me to go to law school. :)
I don't think that they would have a leg to stand on if Bugtraq still posted them. As long as they aren't used to generate profit, I think that reproducing them would fit under the fair use provisions in copyright law.
Anyone want to comment on that?
I take it you have never had to suffer through an NT crash that destroyed the registry so that the machine wasn't bootable. UNIX machines, with their text-based administration is great. You can wrap GUI tools around it so that it's easy to change things in X. However, when the system crashes to the point that you can't use the database tools to fix the system, there is no substitute for using a simple text editor of some sort to prevent having to reformat. I agree that the tendency to toss config files around is a bad idea. I definitely recommend a more organized approach to config files. Say, use an
I agree that a program is a collection of resources and config files as well as the libraries and executables that make it up. Mac OS X has borrowed the NeXTSTEP idea of bundles which shows that this kind of think could be well used in general UNIX. However, you could put resources and stuff in the executable itself by extending the ELF format to hold it (or use ELF notes). You could even have the standard resources in the aforementioned config directory. I think that file forks are a bad idea, however.
I disagree here, too. Yes, having a kernel-supported RPC (similar to NT's LPC -- Local Procedure Call) would be nice, but it's not much more to that than just sending the program a message to a well-defined port and processing the reply. You didn't mention Shared Memory, Semaphores, or Message-Passing when discussing UNIX IPC. These were brought in by SYSV, not BSD, and make excellent additions to the IPC that UNIX has to offer.
Just my
This is where the beauty of OO design comes in. You take an existing object that does most of what you want, derive a new object from it that WILL STILL HAVE THE PREVIOUS INTERFACE AS A SUBSET TO ITS INTERFACE so the new object can be used in place of its parent and voila. There you have it. That is how code reuse can be useful and good.
:) Go GNOME! Go Bouncing Bonobo! (yes, I remember that pre-release).
This was a major concept I taught to a class in C++, and more use should be made of it.
I wouldn't be surprised if there is already a good amount of this going on within the BeOS since it's all in OO C++. C is harder to do OO stuff with, but since gtk+, et. al. are OO in C, it is possible.
Hmmm...I hate to see a good UNIX company having trouble. Sure, it's not open source and all, but open source is not the end-all, be-all of UNIX computing. I love Linux and *BSD, et. al. but it's good to have some official commercial companies showing that you don't have to sell out to Windows.
:)
However, that said...it's possible that this could be a good thing...all those peeps who used SCO could turn around and upgrade to Linux.
I think it was "inheritance" pitfalls, not inherent. :) As to what they are, I'd love to hear the author's explanation as well.
Actually, yes. The "Capabilities" referred to are an SGI spinoff that will allow a piece of software to temporarily take on additional capabilities and then shed them. This will allow finer-grained access control to files and also go a long way towards removing the necessity of having suid-root proggies.
No, we just don't have any alternatives to a good browser.
I am curious...how does OpenLDAP stack up against these two other options? Will Windows2000 machines talk standard LDAP or will we be forced to use Active Directory even if we have an already existing LDAP solution?
Not quite. They would have to start providing source once they start spreading the modified Linux. If they spread machines without Linux on them, they don't have to do diddly about providing source.
The key to 3D acceleration with TNT2 is the Nvidia X Server which is downloadable from their website. It's built against XFree86-3.3.5, so you'll have to have that version of XFree86 installed. They include a rather nice install script that copies the X Server and glx and GL libraries. You will also need to have Mesa installed.
Unfortunately, when I try to get automount to work with smb filesystems, I get the following error messages in /var/log/messages:
/lsi-ou-server/c
e ted' "//lsi-ou-server/c$"
Nov 12 11:23:02 helsinki automount[10387]: attempting to mount entry
Nov 12 11:23:02 helsinki automount[10392]: cannot find mount method for filesystem smbfs
My automount line looks like this:
c -rw,fstype=smbfs,user=administrator,password='del
Thanks for your help and all the wonderful Samba work!
Ummm...that would be Moses, not a bunch of small plants (mosses). :)
You're forgetting Bill Gates and ass are in the same species, so it's already possible.
Too long to compile on an 8MB 386DX33? Then use your kick-a$$ machine to cross-compile the kernel for your 386 machine. :) Ah the wonders of free software. :)
That is not quite correct. The load average is the average number of processes that are eligible to run, but can't over that time period. The three time periods are 5 minutes, 10 minutes, and 15 minutes. Basically, the load average tells you the average size of the ready queue in the system over those time periods. This measure is useful to see if the system is overloaded because if the 15 minute average is quite high, then the system has had a rather large ready queue for quite some time.
- Threading. I'd like to see X get good threading support in it. I know the calls are there for XCreateThread() and friends, but I think that each thread created with XCreateThread() should get their own Xlib queue to talk to the X server. However, they should share all of the XIDs with each other. That way, you don't have to treat EVERY X call as a critical section. Each thread writes to its contact point with Xlib and reads from its private queue.
- GTK+ is a great library. However, I think that the gdk layer is unneeded. gdk is basically a wrapper around Xlib that does virtually the exact same thing as the underlying Xlib call. Yes, there are some differences and for those calls it is OK. However, I think that GTK+ could be more efficient if it were written on top of Xlib instead of on top of gdk on top of Xlib.
Just my musings.DOH! I know you don't have to reboot. I was half-thinking of changing network settings. :) It's still pretty da#n inconvenient to have to log out and log back in, esp. if you want to do things as yourself, too.
grrr... Darn interpretation of HTML. The phrase "opening a socket 1024" should read "opening a socket 1024"...
Properly set up group permissions and memberships can alleviate the need to log in as root most of the time. no program NEEDS to run as root unless it is opening a socket 1024 or directly accessing video hardware since there is no device file for it. Beyond that, it's all based on permissions to the files. You can set up a sysadmin group and make all administrative files in that group and make the proper people members of that group and you can access anything you need without su-ing to root. You can even manage the password file that way (though I wouldn't recommend it).
Ahem...unless the user is also in the Administrators or Domain Admins group. Since Windows has no DECENT su command equivalent, many Administrators put their account in the Administrators and/or Domain Admins groups to make it easier to administer their systems without a reboot.
DAMN HTML interpreting ' and '>'. Here is the insides of the include brackets:
stdio.h
sys/types.h
fcntl.h
aio.h
signal.h
In that order.
Interesting you mention man aio.
I have been trying to test this under Linux to no avail. I have a simple C proggy:
#include
#include
#include
#include
#include
int ok = 0;
void io_handler(int signum)
ok = 1;
void main()
struct aiocb cb;
int fd, retval;
char buf[50];
struct sigevent sigev;
signal(SIGIO, io_handler);
fd = open("test", O_RDONLY);
sigev.sigev_notify = SIGEV_SIGNAL;
sigev.sigev_signo = SIGIO;
cb.aio_fildes = fd;
cb.aio_buf = buf;
cb.aio_nbytes = 15;
cb.aio_sigevent.sigev_notify = SIGEV_SIGNAL;
cb.aio_sigevent.sigev_signo = SIGIO;
fprintf(stderr, "here\n");
aio_read(&cb);
fprintf(stderr, "here\n");
while (!ok) {
fprintf(stderr, "waiting...\n");
sleep(5);
}
fprintf(stderr, "retreived data: %s\n", buf);
}
Works fine under Slowlaris and Irix, but Linux doesn't get the signal. Any ideas? I'd love to believe that Linux supports Async I/O, but I need to prove it to myself first.
Cheers!
Better yet is to just un-rpm kernel and kernel-headers. Ignore the errors. Then, cd to /usr/src and unpack the kernel source there, mv the linux directory to one that is aptly named (linux-2.2.8, in this case), ln -s linux-2.2.28 linux, then unpack the kernel sources and then make the symlinks from /usr/include for linux and asm to /usr/src/linux/include/linux and /usr/src/linux/include/asm, respectively. Finally, go to /usr/src/linux/include and ln -s asm- asm. In my case, I use asm-i386 for the architecture-specific asm headers.
:) Just use the tar.gz's (or bz2 if you prefer them).
After that, NEVER use another RedHat kernel RPM.