Krause left executable versions of all eight programs at issue on Titleserv's file servers, but locked them with a command, which prevented a popular decompiler from converting the executable code back into source code."
Sounds like Visual Basic to me (1996 era VB "compilers" just converted the BASIC program to bytecode with an interpreter stuck on the front). Makes this idiot even more laughable.
How true. I recently migrated an Access DB with only a few hundred thousand records to PostgreSQL. We haven't even optimized the queries yet (just linked tables to the PG backend) and the weekly reports are already 10x faster. And this is over a gigabit LAN -- I'd hate to think of how slow it would be from one of the frame relay sites.
You would be wrong. Access in particular has absolutely shitty backwards compatability - we're currently in the middle of a huge effort at work to upgrade from Access 97. If you even *open* an Access 97 db from Access 2000, it can't be accessed from 97 anymore (which is why we never did a full migration before). Access 2003 can't open 97 databases at all, and Access 2003 refuses (or at least corp. IT can't figure out how) to co-exist with 97 on the same machine the way 2000 can.
Just a tip that may help out a little here. Although Access 2000+ won't let you directly manipulate Access 97 databases without converting them, the Jet DB engine is perfectly capable of R/W access to 97-format databases. One way to have them co-exist is to create a blank database in 2000, then link all the tables from the 97 format database in. By opening the special compatibility database, Access 2000 users can have full read-write capability without having to convert the database.
You can also go the other way (open 2000 format MDBs in 97) if you have a new enough MDAC version installed. A simple linked table won't work, but you can route it through an ODBC data source.
It's an ugly hack, and you still have to manually copy over reports / macros, but it works.
a sufficiently confused immune system might overreact to external stimulus and launch such a strike for no real reason.
Yeah, it's called allergies.
Re:SBC used to be called Southwestern Bell
on
Ma Bell is Back
·
· Score: 1
SBC was originally called Southwestern Bell. It covered the Southwest United States (except for California and Nevada). It was one of the regional "baby Bells" created when ATT was split in the 1980s.
Except for the region where I work (out in the boonies in North Texas). Everywhere else in the area is covered by SBC, but for some unknown reason the small rural area we're in has All-tel as the ILEC. Never did figure that one out, especially as All-tel seems primarily focused on the cellular market.
I never quite bought that. You'd think the biology teacher would get suspicious when someone he no doubt clearly remembers giving a failing grade to doesn't repeat the course.
Ironically when he pointed this out to them, they were actually nice about it, thanked him and promptly changed the password.
The difference here being that he was (a) a paying customer, and (b) rightly concerned about the security of the data he was going to be trusting to said paid service.
If they weren't nice about something like that they would be out of business in no time.
Congratulations, you've found THE killer app for Outlook/Exchange. Seriously, it is probably the best out there right now.
Maybe, maybe not. One thing Outlook/Exchange doesn't seem to be good at is scheduling for small close-knit groups (i.e. a small 4-5 person department that needs to coordinate a lot of things). Switching back and forth is inefficient, a shared calendar in a public folder can make it hard to figure out whose appointments are whose and reminders don't work, using meeting requests for everything is overkill, and the new "Group Schedules" in Outlook 2003 is a joke.
It would be nice if Outlook had a layered calendar view like KOrganizer does.
Well, I haven't tracked down exactly what causes it, but I've experienced it when using MakeMSI. Occassionally when there is an error in the input file, it will print the normal error message and beep, but then hang rather than returning to the command prompt. At this point, the reg4mm process is unkillable. You can still move the mouse and do things like move windows around, but anything that touches any file system will immedately freeze. Do a "dir" in another command prompt and it will never come back. Can't even do a clean shutdown -- when it happens I have to reach for the power button.
It's fairly easy to reproduce -- I've made it happen on a few different machines running Windows XP and 2003 server. Haven't tried 2000 yet but I suspect it would happen there as well. Doesn't need an admin account either, just a standard user is enough.
My input files and current directory are usually located on a Samba share, but I'm pretty sure I've managed to freeze it up even when everything's on the local disk.
most remarkably virii and malware manage to get unkillable quite easily. Flaky security or the unability to chmod your stuff may have something to do with it.
A lot of malware isn't unkillable in the traditional sense. What it does is run 2 processes that act as a watchdog for each other. Kill one and the other one starts it back up. They probably got the idea from MS even -- back in the day Windows used two system threads that watched out for each other and kept you from tweaking the registry key to turn NT Workstation into NT Server.
A technique I like to use for killing those is to find the EXE file that is being re-launched every time you kill it. You won't be able to delete it because of Win32's breaindead filesystem semantics, but you can change permissions on it to deny access to everyone. Then when you kill one of the processes, the other one isn't able to start it back up. I've yet to see any malware smart enough to change permissions back on the file, so for now anyway it's an effective way to kill them.
It's asked nicely first. 20 seconds later, you get the "End Now" button in the dialog box. If you click it, the process address space is torn down.
See my reply to the parent post -- I'm referring to the "End Process" button, which kills it immediately. The "End Task" button on the other tab sends a WM_QUIT first and gives the app a chance to shut down.
The difference is, in unix type systems, SIGTERM and SIGKILL are handled by the OS and the process is only informed of them (so it can try to shut down properly), in Windows, the process is being asked nicely to close. Windows process is free to ignore these events.
No, no, and no. It's true that in the "Tasks" or "Applications" tab, hitting End Task will send a request (WM_QUIT) to exit. That's not what I'm talking about. I mean the Processes tab. That is handled by the OS; it routes through Win32 first but ends up at NtTerminateProcess (ZwTerminateProcess). Go read the API reference or even the DDK if you don't believe me. Maybe in the dark days of Win9x that was true, but the NT kernel is a real OS, no matter what other crap you layer on top of it.
There are only three states a process can be in where it's unkillable.
1. "Access denied". This happens on some system processes because they run as the user SYSTEM (equivalent to root), where your task manager process is not. The security descriptor on those processes is set so that nobody except SYSTEM (not even Administrators) can kill them. They can be killed by running task manager as SYSTEM. There are various methods to run a process under the system account; the easiest is by using the "at" command to have the scheduler service start it. Newer versions of task manager also have a list of processes it will refuse to kill, but you can still kill them by using pskill or some other third-party utility that has no such restrictions.
2. Process is stuck in the kernel somewhere. Happens when system calls never return, which isn't supposed to happen. Often due to bad drivers -- even with flaky hardware it SHOULD timeout eventually. I've seen add-on firewall software that hooks the TCP stack and can cause this condition. Sometimes you can get one unstuck by kicking the kernel in the head (i.e. removing or stopping the offending device), otherwise a reboot is the only way to clear it. Unless you're running a checked build with a remote serial debugger, but not many people outside of driver developers do that.
3. Process has a debugger attached. In this case, simply kill the debugger instead.
The worst part is that Windows doesn't have an unconditional kill so some process just never dies and never lets go of all the files and handles.
Yes it does. Killing a process from task manager is the same thing as kill -9. When the process dies it unconditionally releases all file handles, mutexes, and any other resources that it had open.
The only time that won't work is if the process is stuck in a system call somewhere (i.e. in the kernel). That usually means buggy device drivers which unfortunately are all too common in the Windows world. It could also be a bona-fide kernel bug, though those are fairly rare (but I do know of one way to cause a vfs lockup on any version of NT -- including fully patched 2k3 server -- without admin rights).
I see the same thing happen all the time on Linux. For example if a process is stuck trying to read a file that's on an nfs server that has become unreachable, not even kill -9 will get rid of it. Even *BSD sometimes gets unkillable processes in cases where the underlying hardware has gone to lunch. I see it sometimes with flaky CD burners, for example.
My only issue for IPv6 is older operating systems that are still used, in the consumer market, Win9x, WinNT, and even Win2k do not have IPv6 stacks
AMEN. If anything I would expect Microsoft to be pushing IPv6, because it's the one thing that WinXP has that Win2k doesn't. A lot of businesses are sticking with Win2k because XP has no compelling new features and adds a lot of useless crap.
Not all 128 bits are usable in an IPv6 address. Only the top 48 is issued on a per-customer basis from ISPs, and the next 16 bits are used for internal routing on the customers network. The bottom 64 bits are all network-local address. Nobody in their right mind would try to put 2^64 hosts on a single subnet, so there will be a LOT of unused space.
Yes, you can set up different routing internally if you really want to, but the bottom line is the 48-bit prefix per end-user bit is established in the standard and what will be assigned. Add hierarchical routing on top of that, and even more address space will be wasted.
Slashdot Mirror
Where is the fine line between encoding and encryption drawn?
Is Unicode encryption?
Is UTF-8 encryption?
Horse shit indeed...
Krause left executable versions of all eight programs at issue on Titleserv's file servers, but locked them with a command, which prevented a popular decompiler from converting the executable code back into source code."
Sounds like Visual Basic to me (1996 era VB "compilers" just converted the BASIC program to bytecode with an interpreter stuck on the front). Makes this idiot even more laughable.
...you'll need to contact your IT department to have them install the software for you.
ROTFL! That has to be a joke. No competent IT department would install shit like this, even if it wasn't malicious.
Blame Apple. ...and the fact that making shiny round things in vector art programs is really easy.
Uhm, no. It isn't that big at all. About 2 gig for the db server.
/usr/ports/distfiles/postgresql/
2 gig?!?!?! For a DB server?! Not big at all?!!!!!
$ ls -l
-rw-r--r-- 1 root wheel 7825300 Oct 3 20:25 postgresql-base-8.0.4.tar.bz2
-rw-r--r-- 1 root wheel 2227623 Oct 3 20:26 postgresql-docs-8.0.4.tar.bz2
-rw-r--r-- 1 root wheel 389944 Apr 10 2005 postgresql-jdbc-8.0-311.src.tar.gz
-rw-r--r-- 1 root wheel 133881 Oct 3 20:26 postgresql-opt-8.0.4.tar.bz2
OPEN(2) FreeBSD System Calls Manual OPEN(2)
...);
NAME
open -- open or create a file for reading or writing
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <fcntl.h>
int
open(const char *path, int flags,
The flags specified are formed by or'ing the following values
O_NOFOLLOW do not follow symlinks
How true. I recently migrated an Access DB with only a few hundred thousand records to PostgreSQL. We haven't even optimized the queries yet (just linked tables to the PG backend) and the weekly reports are already 10x faster. And this is over a gigabit LAN -- I'd hate to think of how slow it would be from one of the frame relay sites.
You would be wrong. Access in particular has absolutely shitty backwards compatability - we're currently in the middle of a huge effort at work to upgrade from Access 97. If you even *open* an Access 97 db from Access 2000, it can't be accessed from 97 anymore (which is why we never did a full migration before). Access 2003 can't open 97 databases at all, and Access 2003 refuses (or at least corp. IT can't figure out how) to co-exist with 97 on the same machine the way 2000 can.
Just a tip that may help out a little here. Although Access 2000+ won't let you directly manipulate Access 97 databases without converting them, the Jet DB engine is perfectly capable of R/W access to 97-format databases. One way to have them co-exist is to create a blank database in 2000, then link all the tables from the 97 format database in. By opening the special compatibility database, Access 2000 users can have full read-write capability without having to convert the database.
You can also go the other way (open 2000 format MDBs in 97) if you have a new enough MDAC version installed. A simple linked table won't work, but you can route it through an ODBC data source.
It's an ugly hack, and you still have to manually copy over reports / macros, but it works.
a sufficiently confused immune system might overreact to external stimulus and launch such a strike for no real reason.
Yeah, it's called allergies.
SBC was originally called Southwestern Bell. It covered the Southwest United States (except for California and Nevada). It was one of the regional "baby Bells" created when ATT was split in the 1980s.
Except for the region where I work (out in the boonies in North Texas). Everywhere else in the area is covered by SBC, but for some unknown reason the small rural area we're in has All-tel as the ILEC. Never did figure that one out, especially as All-tel seems primarily focused on the cellular market.
I left the place after 2 days of work in disgust at this and the other equally shady practices of this dodgy company.
Not to mention too dumb to figure out how to simply set permissions on mailboxes.
Ah the days when changing a grade was easy.
I never quite bought that. You'd think the biology teacher would get suspicious when someone he no doubt clearly remembers giving a failing grade to doesn't repeat the course.
Ironically when he pointed this out to them, they were actually nice about it, thanked him and promptly changed the password.
The difference here being that he was (a) a paying customer, and (b) rightly concerned about the security of the data he was going to be trusting to said paid service.
If they weren't nice about something like that they would be out of business in no time.
Congratulations, you've found THE killer app for Outlook/Exchange. Seriously, it is probably the best out there right now.
Maybe, maybe not. One thing Outlook/Exchange doesn't seem to be good at is scheduling for small close-knit groups (i.e. a small 4-5 person department that needs to coordinate a lot of things). Switching back and forth is inefficient, a shared calendar in a public folder can make it hard to figure out whose appointments are whose and reminders don't work, using meeting requests for everything is overkill, and the new "Group Schedules" in Outlook 2003 is a joke.
It would be nice if Outlook had a layered calendar view like KOrganizer does.
It resists virtual scratches?
Dammit, you had me all excited thinking I could get one for 5 bucks! :-P
...and remember to read at least one of said scrolls while confused.
Well, I haven't tracked down exactly what causes it, but I've experienced it when using MakeMSI. Occassionally when there is an error in the input file, it will print the normal error message and beep, but then hang rather than returning to the command prompt. At this point, the reg4mm process is unkillable. You can still move the mouse and do things like move windows around, but anything that touches any file system will immedately freeze. Do a "dir" in another command prompt and it will never come back. Can't even do a clean shutdown -- when it happens I have to reach for the power button.
It's fairly easy to reproduce -- I've made it happen on a few different machines running Windows XP and 2003 server. Haven't tried 2000 yet but I suspect it would happen there as well. Doesn't need an admin account either, just a standard user is enough.
My input files and current directory are usually located on a Samba share, but I'm pretty sure I've managed to freeze it up even when everything's on the local disk.
most remarkably virii and malware manage to get unkillable quite easily. Flaky security or the unability to chmod your stuff may have something to do with it.
A lot of malware isn't unkillable in the traditional sense. What it does is run 2 processes that act as a watchdog for each other. Kill one and the other one starts it back up. They probably got the idea from MS even -- back in the day Windows used two system threads that watched out for each other and kept you from tweaking the registry key to turn NT Workstation into NT Server.
A technique I like to use for killing those is to find the EXE file that is being re-launched every time you kill it. You won't be able to delete it because of Win32's breaindead filesystem semantics, but you can change permissions on it to deny access to everyone. Then when you kill one of the processes, the other one isn't able to start it back up. I've yet to see any malware smart enough to change permissions back on the file, so for now anyway it's an effective way to kill them.
It's asked nicely first. 20 seconds later, you get the "End Now" button in the dialog box. If you click it, the process address space is torn down.
See my reply to the parent post -- I'm referring to the "End Process" button, which kills it immediately. The "End Task" button on the other tab sends a WM_QUIT first and gives the app a chance to shut down.
The difference is, in unix type systems, SIGTERM and SIGKILL are handled by the OS and the process is only informed of them (so it can try to shut down properly), in Windows, the process is being asked nicely to close. Windows process is free to ignore these events.
No, no, and no. It's true that in the "Tasks" or "Applications" tab, hitting End Task will send a request (WM_QUIT) to exit. That's not what I'm talking about. I mean the Processes tab. That is handled by the OS; it routes through Win32 first but ends up at NtTerminateProcess (ZwTerminateProcess). Go read the API reference or even the DDK if you don't believe me. Maybe in the dark days of Win9x that was true, but the NT kernel is a real OS, no matter what other crap you layer on top of it.
There are only three states a process can be in where it's unkillable.
1. "Access denied". This happens on some system processes because they run as the user SYSTEM (equivalent to root), where your task manager process is not. The security descriptor on those processes is set so that nobody except SYSTEM (not even Administrators) can kill them. They can be killed by running task manager as SYSTEM. There are various methods to run a process under the system account; the easiest is by using the "at" command to have the scheduler service start it. Newer versions of task manager also have a list of processes it will refuse to kill, but you can still kill them by using pskill or some other third-party utility that has no such restrictions.
2. Process is stuck in the kernel somewhere. Happens when system calls never return, which isn't supposed to happen. Often due to bad drivers -- even with flaky hardware it SHOULD timeout eventually. I've seen add-on firewall software that hooks the TCP stack and can cause this condition. Sometimes you can get one unstuck by kicking the kernel in the head (i.e. removing or stopping the offending device), otherwise a reboot is the only way to clear it. Unless you're running a checked build with a remote serial debugger, but not many people outside of driver developers do that.
3. Process has a debugger attached. In this case, simply kill the debugger instead.
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
Okay, pen and sword are easy enough -- what's the hand gesture for "court"?
The worst part is that Windows doesn't have an unconditional kill so some process just never dies and never lets go of all the files and handles.
Yes it does. Killing a process from task manager is the same thing as kill -9. When the process dies it unconditionally releases all file handles, mutexes, and any other resources that it had open.
The only time that won't work is if the process is stuck in a system call somewhere (i.e. in the kernel). That usually means buggy device drivers which unfortunately are all too common in the Windows world. It could also be a bona-fide kernel bug, though those are fairly rare (but I do know of one way to cause a vfs lockup on any version of NT -- including fully patched 2k3 server -- without admin rights).
I see the same thing happen all the time on Linux. For example if a process is stuck trying to read a file that's on an nfs server that has become unreachable, not even kill -9 will get rid of it. Even *BSD sometimes gets unkillable processes in cases where the underlying hardware has gone to lunch. I see it sometimes with flaky CD burners, for example.
My only issue for IPv6 is older operating systems that are still used, in the consumer market, Win9x, WinNT, and even Win2k do not have IPv6 stacks
AMEN. If anything I would expect Microsoft to be pushing IPv6, because it's the one thing that WinXP has that Win2k doesn't. A lot of businesses are sticking with Win2k because XP has no compelling new features and adds a lot of useless crap.
Not all 128 bits are usable in an IPv6 address. Only the top 48 is issued on a per-customer basis from ISPs, and the next 16 bits are used for internal routing on the customers network. The bottom 64 bits are all network-local address. Nobody in their right mind would try to put 2^64 hosts on a single subnet, so there will be a LOT of unused space.
Yes, you can set up different routing internally if you really want to, but the bottom line is the 48-bit prefix per end-user bit is established in the standard and what will be assigned. Add hierarchical routing on top of that, and even more address space will be wasted.