I wouldn't discontinue looking. There are a lot of possible collisions for any given message, and I'd like to find as many as I can to increase the liklihood that one of them is useful.
I maintain no illusions of equality. I have never nor do I plan on starting. I follow the classic line of reasoning that if it's good for me, then good. If its good for me and bad for you, not-so-great, but at least it's good for me. If it's good for me and good for you, great. Basically, I am looking out for myself, and my immediate neighbors that I am in contact with.
If you talk to governments of a given country, it damn well better be saying the same thing, less there is need for a revolution. The purpose of a government is to first and foremost, promote the welfare of its own citizens, even, gasp, over the welfare of citizens from other nations.
The same thing can be done on Linux/Unix with any ldap or sql server and remedial skills with a particular language (perl, python, java, etc). It is a custom job, and no GUI exists (as it would be a custom GUI) unless you count offerings from Sun, Novell, and IBM. In fact, now that I think about, Linux/Unix has this exact same functionality. If you go with a custom solution, it is even included with the cost of a good admin or two, no license required.
Actually this is no longer true. KDE has been building with the Native QT3 for the Mac for awhile now w/o X11. Using the same idea of targeting QT only, you should (theoretically) get a Win32 native build. This would kick ass if they get the stability of the X11-less build equal to the X11 version. Right now, the KDE for OS X project is alpha-ish at best, with random crashing and such, but at least some applications are usable (KOffice, most notably).
I'm not sure about GNOME (I don't use it), but SUSE 9.2 Pro's KDE had this. The version of KDE that I built from ports on FreeBSD 5.3-STABLE didn't have this so I think that SUSE's team may have backported this from KDE CVS or patched it in themselves.
As an ECU engineer, can you assure me that in 2010 I wont have a car running on a SINGLE OS which would be susceptible to failure?
Then again, forget the tail end; would it run a single operating system?
I can't say for 100% (we're only on '08 software right now), but i am 99.99999999999999% sure that it won't happen. The reason I'm sure is economics.
Each ECU has a different hardware with a lot of the ECUs running homegrown OSs. In order to standardize, you would have to standardize on the most powerful hardware in order to run a more generic real-time OS. That won't happen because more powerful hardware is more expensive. We would be looking at moving from something like a 16bit x86-based micro like the M16C from Renesas to a 68k chip that is used an engine controller. That is an increase in cost that is simply unacceptable when you are mulitplying it by millions of units.
Hell, my project can't even move from 32k flash to 64k flash for features, let alone standardization.
As an ECU engineer (Chrysler products right now), I tell you that the chances of this happening can be expressed as 1/infinity (0). Well, it is possible that this could happen on older cars, but not newer systems.
A brief overview of the car's computer architecture is needed to understand why. Our cars today are filled with electronic devices that are connected in a network. Think of the car as a computer lab with computers connected via a bunch of different hardware: gigabit ethernet for some, 10/100 for others, and serial connections for some others. Each of these computers has a single purpose and all the computers have to talk to each other to get the information they need to complete their tasks.
On the autos, we call these networks CAN (B/C mostly) (similiar to ethernet, but at 1Mbit max theoretical speed and 500kbps max practical speed, and LIN (along with some others, but I'm not familiar with them) (a sort of serial protocol). We then separate all of the computers on the network, called ECUs, into different levels depending on how critical they are, and how much information they need to relay.
For example, the engine controller is very important to your car, so it goes on high-speed CAN (CAN C) and does not interact with low-speed CAN except via a gateway. As you may have guessed, ECUs on high-speed CAN are audited and tested much more than their low-speed counterparts (ie. you'd be angry if your radio failed, but you'd be fucked if your brakes suddenly stopped working; suppliers test accordingly).
Radios usually include a clock functionality and is used to synchronize various ECUs. Because the high-speed ECUs require much more precise timing, the radio was put on the high-speed CAN bus. So, in older cars, a seriously malfunctioning radio, could potentially saturate the high-speed bus.
Maybe. Because of the way CAN was designed, priority is given to the holder of the lowest message id in the event of messages being sent out on the bus at the same time. So, the important systems like your engine controller and your ABS system would likely have priority over your radio. Unfortunately, something like resource exaustion could possibly take place with an ECU gone haywire and performing a D.O.S., but it isn't very likely.
Recently, this design decision was rethought and we think we have fixed it.
My university supposedly requires all machines to have virus scanners installed. I talked to IT and they told me that if I was smart enough to install FreeBSD then I was smart enough to not contract a Windows virus or worm. That said, it was slightly easier for me to get my machine up and running that other people. All I did was plug my machine in, and FreeBSD magically configured itself like a good dhcp client is supposed to.
I know some people using windows that still can't get the (required, but not for me) proxy and virus software to install.
This is probably just me, but I have never seen YaST have a remotely usable speed. At a workstation with a supported motherboard with an amd64 processor, a supported SATA controller with a drive running a 7.2kRPM, a support video card, 1gig of tested memory and using only SuSE packages with nothing other than the default KDE install running, YaST should not lag. And it lags bad. Nothing else in my SuSE install is so slow. Waiting 20 seconds for a new window to load is simply unacceptable. I don't want to image how long it would take using X remotely.
The really odd thing is that I've NEVER seen a fast version of YaST. I've used SUSE for many years but the graphical configuration tool really pisses me off.
I've been a Gentoo user in the past and really like the distro, but selinux or grsecurity policies do no automagically translate into security. Each policy has to be configured for each system, and you still have the problem with portage being bleeding-edge and not entirely stable./typing this from a FreeBSD-current install and thus in the same boat
When I was finished backing up and installing on fresh hardware and had the backup for that hardware installed properly, I did this. I started off with disconnecting the hard drive. FreeBSD didn't seem to care. Apache kept on running as did ftp, ssh, and my firewall routing. I thought that nature would take its course and just left. A couple days later I came back, and to my suprise the damn system was still live and functioning. Kinda pissed off, I ssh'd in and rm -rf/'d as root and the damn system still didn't die.
The console collected a whole lot of error messages, but at 25 lines I could only have 25 at a time and since/var was no longer present, I only had to deal with an error for 25 lines before it dealt with itself. Eventually, I just pulled the plug. FreeBSD 4 really is unkillable. It might complain when you try to kill it but lack of hardware doesn't seem to make a difference to FreeBSD.
Nice.
As a FreeBSD user myself (only OS I run currently), I'll disagree that it's secure out of the box. The exception is syslogd which is configured to run on all interfaces out of the box. This can be a bad thing. Other than that, it's decent. Run a sockstat -4 on a FreeBSD machine after an initial install to see what I'm talking about.
The easy thing for the kid to do is to bum rides off other people. It worked great for me. I hate cell phones, even now that my only phone is a cell phone. I usually can go for a couple weeks between charges, and my charge only holds for about a day./driving sucks//driving in chicago sucks more///is 18 and on my own so don't give me crap about responsibility
It seems to me that trying to round up all the people who actively support the right for them to keep their guns just for an event such as this would be a very bad idea.
1) These tools suck against encryption. loopback twofish and/or loopback aes. This alone would be enough to halt most investigations.
2) Proper disposal of the filesystems. I'm not talking reformatting (that's where they get you, the reformat only erases the book keeping information and not the actual data), I'm talking about "dd dev=/dev/zero of=/dev/hda" around 10 times for good measure and using a decent filesystem to begin with (Ever tried reconstructing a reiserfs partition? You don't want to, especially one that has a fraction of its original data unchanged.)
3) Well-configured security settings of the base OS to prevent attacking and breaking the running system.
A couple ideas on this. (Note: none of these are perfect, but they work very well for me.)
Update the system using cvsup or anoncvs and then go to the directory of the changed file. Run make clean && make and then take a quick peak into the Makefile. Note where the program is installed to, and then place it there.
Now, from the system root (/), run "tar -czvf binary-update.tgz/path/to/binary". Distribute the resulting tgz and unpack it in the root directory. This can be automated with scp, ssh, and a bit of ksh script. In fact, I bet the whole thing could be automated for programs since OpenBSD uses statically compiled binaries when at all possible.
I woudl suggest blocking (or null routing) them ALL, but then the DDoS attacker will just go buy another set of zombie PCs and renew the attack. You can't win that one.
Yes you can. Keeping a counter on hits from a particular IP isn't difficult and can be done efficiently. When it reaches a certain amount in a specified time range, blacklist the IP for a random amount of time.
This deals with customers being denied access (if they are sending out packets at 100% bandwidth utilization then they aren't using their pc now or in the immediate future anyway). This also effectively prevents a DDoS when combined with spoof protection. With the backing of ISPs using anti-spoofing filtering, this could effectively eliminate a DDoS.
Python uses the native RAD environment. On Mac OS X, it uses Xcode. On systems with QT it uses QTDesigner+KDevelop. On Windows, there are several projects that build windows interfaces (Glade2 if you go the GTK+2 route.) including a commercial Visual Studio plugin. On GTK, you of course have Glade. (Glade2 for GTK+2.)
Personally, I don't think you need a RAD tool. Python + An Editor works very well for me. Then again, I use easygui (and some custom additions) which is an abstraction of Tk with Python. AquaTK is simply beautiful.
As to the other languages, I'm pretty sure they all hook into at least KDevelop and Glade. I don't know about Xcode and Visual Studio though.
Slashdot Mirror
You can have my membership card if I have to listen to this shit. *points* I'll be over there listening to Nevermore and Soilwork if you need me.
I wouldn't discontinue looking. There are a lot of possible collisions for any given message, and I'd like to find as many as I can to increase the liklihood that one of them is useful.
I maintain no illusions of equality. I have never nor do I plan on starting. I follow the classic line of reasoning that if it's good for me, then good. If its good for me and bad for you, not-so-great, but at least it's good for me. If it's good for me and good for you, great. Basically, I am looking out for myself, and my immediate neighbors that I am in contact with.
If you talk to governments of a given country, it damn well better be saying the same thing, less there is need for a revolution. The purpose of a government is to first and foremost, promote the welfare of its own citizens, even, gasp, over the welfare of citizens from other nations.
The same thing can be done on Linux/Unix with any ldap or sql server and remedial skills with a particular language (perl, python, java, etc). It is a custom job, and no GUI exists (as it would be a custom GUI) unless you count offerings from Sun, Novell, and IBM. In fact, now that I think about, Linux/Unix has this exact same functionality. If you go with a custom solution, it is even included with the cost of a good admin or two, no license required.
That's interesting. I have not met one person here who was sober enough to use one of their PCs, regardless of the OS.
Actually this is no longer true. KDE has been building with the Native QT3 for the Mac for awhile now w/o X11. Using the same idea of targeting QT only, you should (theoretically) get a Win32 native build. This would kick ass if they get the stability of the X11-less build equal to the X11 version. Right now, the KDE for OS X project is alpha-ish at best, with random crashing and such, but at least some applications are usable (KOffice, most notably).
I'm not sure about GNOME (I don't use it), but SUSE 9.2 Pro's KDE had this. The version of KDE that I built from ports on FreeBSD 5.3-STABLE didn't have this so I think that SUSE's team may have backported this from KDE CVS or patched it in themselves.
As an ECU engineer, can you assure me that in 2010 I wont have a car running on a SINGLE OS which would be susceptible to failure?
Then again, forget the tail end; would it run a single operating system?
I can't say for 100% (we're only on '08 software right now), but i am 99.99999999999999% sure that it won't happen. The reason I'm sure is economics.
Each ECU has a different hardware with a lot of the ECUs running homegrown OSs. In order to standardize, you would have to standardize on the most powerful hardware in order to run a more generic real-time OS. That won't happen because more powerful hardware is more expensive. We would be looking at moving from something like a 16bit x86-based micro like the M16C from Renesas to a 68k chip that is used an engine controller. That is an increase in cost that is simply unacceptable when you are mulitplying it by millions of units.
Hell, my project can't even move from 32k flash to 64k flash for features, let alone standardization.
As an ECU engineer (Chrysler products right now), I tell you that the chances of this happening can be expressed as 1/infinity (0). Well, it is possible that this could happen on older cars, but not newer systems.
A brief overview of the car's computer architecture is needed to understand why. Our cars today are filled with electronic devices that are connected in a network. Think of the car as a computer lab with computers connected via a bunch of different hardware: gigabit ethernet for some, 10/100 for others, and serial connections for some others. Each of these computers has a single purpose and all the computers have to talk to each other to get the information they need to complete their tasks.
On the autos, we call these networks CAN (B/C mostly) (similiar to ethernet, but at 1Mbit max theoretical speed and 500kbps max practical speed, and LIN (along with some others, but I'm not familiar with them) (a sort of serial protocol). We then separate all of the computers on the network, called ECUs, into different levels depending on how critical they are, and how much information they need to relay.
For example, the engine controller is very important to your car, so it goes on high-speed CAN (CAN C) and does not interact with low-speed CAN except via a gateway. As you may have guessed, ECUs on high-speed CAN are audited and tested much more than their low-speed counterparts (ie. you'd be angry if your radio failed, but you'd be fucked if your brakes suddenly stopped working; suppliers test accordingly).
Radios usually include a clock functionality and is used to synchronize various ECUs. Because the high-speed ECUs require much more precise timing, the radio was put on the high-speed CAN bus. So, in older cars, a seriously malfunctioning radio, could potentially saturate the high-speed bus.
Maybe. Because of the way CAN was designed, priority is given to the holder of the lowest message id in the event of messages being sent out on the bus at the same time. So, the important systems like your engine controller and your ABS system would likely have priority over your radio. Unfortunately, something like resource exaustion could possibly take place with an ECU gone haywire and performing a D.O.S., but it isn't very likely.
Recently, this design decision was rethought and we think we have fixed it.
KOrganizer runs under Cygwin on WinXP if you really want it to.
I know what you mean, but just saying.
My university supposedly requires all machines to have virus scanners installed. I talked to IT and they told me that if I was smart enough to install FreeBSD then I was smart enough to not contract a Windows virus or worm. That said, it was slightly easier for me to get my machine up and running that other people. All I did was plug my machine in, and FreeBSD magically configured itself like a good dhcp client is supposed to.
I know some people using windows that still can't get the (required, but not for me) proxy and virus software to install.
Nice one guys.
Ahem, 9.2 Professional from the DVD. It's the x86-64 edition too. I do configure my system properly, I've simply stopped using YaST.
The really odd thing is that I've NEVER seen a fast version of YaST. I've used SUSE for many years but the graphical configuration tool really pisses me off.
Outside of that, great system.
I've been a Gentoo user in the past and really like the distro, but selinux or grsecurity policies do no automagically translate into security. Each policy has to be configured for each system, and you still have the problem with portage being bleeding-edge and not entirely stable. /typing this from a FreeBSD-current install and thus in the same boat
When I was finished backing up and installing on fresh hardware and had the backup for that hardware installed properly, I did this. I started off with disconnecting the hard drive. FreeBSD didn't seem to care. Apache kept on running as did ftp, ssh, and my firewall routing. I thought that nature would take its course and just left. A couple days later I came back, and to my suprise the damn system was still live and functioning. Kinda pissed off, I ssh'd in and rm -rf /'d as root and the damn system still didn't die.
The console collected a whole lot of error messages, but at 25 lines I could only have 25 at a time and since /var was no longer present, I only had to deal with an error for 25 lines before it dealt with itself. Eventually, I just pulled the plug. FreeBSD 4 really is unkillable. It might complain when you try to kill it but lack of hardware doesn't seem to make a difference to FreeBSD.
Nice.
As a FreeBSD user myself (only OS I run currently), I'll disagree that it's secure out of the box. The exception is syslogd which is configured to run on all interfaces out of the box. This can be a bad thing. Other than that, it's decent. Run a sockstat -4 on a FreeBSD machine after an initial install to see what I'm talking about.
The easy thing for the kid to do is to bum rides off other people. It worked great for me. I hate cell phones, even now that my only phone is a cell phone. I usually can go for a couple weeks between charges, and my charge only holds for about a day. /driving sucks //driving in chicago sucks more ///is 18 and on my own so don't give me crap about responsibility
It seems to me that trying to round up all the people who actively support the right for them to keep their guns just for an event such as this would be a very bad idea.
You, my good Sir, have lost the privilege of calling yourself a geek. All real geeks know that 'geeks' does not use an apostrophe.
Damn poseurs.
emacs
A couple things to add to this:
1) These tools suck against encryption. loopback twofish and/or loopback aes. This alone would be enough to halt most investigations.
2) Proper disposal of the filesystems. I'm not talking reformatting (that's where they get you, the reformat only erases the book keeping information and not the actual data), I'm talking about "dd dev=/dev/zero of=/dev/hda" around 10 times for good measure and using a decent filesystem to begin with (Ever tried reconstructing a reiserfs partition? You don't want to, especially one that has a fraction of its original data unchanged.)
3) Well-configured security settings of the base OS to prevent attacking and breaking the running system.
A couple ideas on this. (Note: none of these are perfect, but they work very well for me.)
/path/to/binary". Distribute the resulting tgz and unpack it in the root directory. This can be automated with scp, ssh, and a bit of ksh script. In fact, I bet the whole thing could be automated for programs since OpenBSD uses statically compiled binaries when at all possible.
Update the system using cvsup or anoncvs and then go to the directory of the changed file. Run make clean && make and then take a quick peak into the Makefile. Note where the program is installed to, and then place it there.
Now, from the system root (/), run "tar -czvf binary-update.tgz
I woudl suggest blocking (or null routing) them ALL, but then the DDoS attacker will just go buy another set of zombie PCs and renew the attack. You can't win that one. Yes you can. Keeping a counter on hits from a particular IP isn't difficult and can be done efficiently. When it reaches a certain amount in a specified time range, blacklist the IP for a random amount of time. This deals with customers being denied access (if they are sending out packets at 100% bandwidth utilization then they aren't using their pc now or in the immediate future anyway). This also effectively prevents a DDoS when combined with spoof protection. With the backing of ISPs using anti-spoofing filtering, this could effectively eliminate a DDoS.
Python uses the native RAD environment. On Mac OS X, it uses Xcode. On systems with QT it uses QTDesigner+KDevelop. On Windows, there are several projects that build windows interfaces (Glade2 if you go the GTK+2 route.) including a commercial Visual Studio plugin. On GTK, you of course have Glade. (Glade2 for GTK+2.)
Personally, I don't think you need a RAD tool. Python + An Editor works very well for me. Then again, I use easygui (and some custom additions) which is an abstraction of Tk with Python. AquaTK is simply beautiful.
As to the other languages, I'm pretty sure they all hook into at least KDevelop and Glade. I don't know about Xcode and Visual Studio though.