I agree. Right now my home system is getting ~22kB/s down, ~3kB/s up. (I forced an upload cap to prevent saturation, I have eDonkey running @10kB/s up too;)
Long story short, the now estimated 20 hour download is much better than the alternative. I'm running RedHat 8 right now. I'm kind of anxious to see what is new in 9. I'll probably spin over to redhat.com sometime today to see what all the fuss is about. Maybe they're finally LSB compliant.:)
Gotta love it. 29KBps upstream, 0 KBps downstream, and I only have a few bytes worth of valid data. Oh yeah, she scales real well. Hehe. Oh well. 78hours is still sooner than 1 week + fight for FTP time. I should probably restart with an upload cap though. My poor 256k sync here at work isn't liking the flooded upstream too much.;)
My dad wrote some CNC control software that would work quite well for this application. It's designed to run anything from table top machines (such as this) all the way up to large scale CNC retrofits, where the iron is good but the control is shot. Very competitively priced as well. Even has a free demo version with no time limit for those that want to check it out. Requires a dos based machine to run it on though. FreeDOS works fine, of course so does MS-DOS.
I'm sure this will kill his pipe, but here is a link: www.cnczeus.com
It's listed in google as well, so you may want to check that out if/when the pipe goes dead from the load.:)
why do you think that ip6 is going to remove the necessity of NAT? I've seen several network installations that use 1-to-1 NAT. This configuration does not cause anywhere near the number of problems that you are thinking of. I can even think of one site that used 1-to-1 NAT twice on the same network block. Once to go from public IP to a private range, and then on the other side of the network another router did 1-to-1 NAT back to the packets' original IP.
Not to mention that many users of consumer level NATing devices (Cable/DSL routers) do so for financial reasons, not out of necessity. Why pay your ISP for another IP address when you can run upwards of 200 machines on the one you already have.
My spouse works for the cable co, so I get free cable modem service, but I only have 1 IP because I'd rather not play the dhcp game with every machine on my home network, praying that they stay within the same subnet so they can talk to eachother directly. Plus, I don't like the idea of all of my local traffic being bridged to the NOC just because the modem firmware doesn't know any better.
Nice small form factor, like Mini-ITX. 1 AGP slot, 2 PCI slots Onboard LAN
AthlonXP supporting chipset 2GB max ram
This way, I have onboard lan, can choose my own video card, choose my own sound card, and still have another slot left incase the onboard lan dies, or incase i need a modem for dialup.
I haven't looked very hard, but most mini-itx boards i see have onboard video and sound, which pretty much sucks for anyone planning on doing anymore more than word processing.
sorry about the 2nd thread, but I figured you wouldn't see this unless I posted this way.
After sleeping on it, I thought of another reason why shared memory doesn't work. Objects that have filehandle references won't correctly persist, since the stream is closed when the php instance shuts down.
A good example of why this is important is dabatase connection pooling. I've worked on a few large commercial websites, written in ASP, backended by Oracle. The system was already existing when I got there, I just helped make a few updates. The interesting part is that the pages were written to share a single database connection that persisted between requests. With a cluster of 25 webservers, and a few million hits a day, it was important to keep the database connections persistant to reduce the connect/disconnect load on Oracle. Instead of having to authenticate over a million connections a day, the Oracle DB was only required to authenticate a webserver on the first request served. The allowed the database to focus on serving out the required data, rather than fussing about opening and closing sockets all day long.
Unfortunately, there are issues with using shared memory that would be better off handled by PHP itself. The integer keys need to be unique, which can be a bit of a pain to generate in the first place, but also lead to issues if other software isn't written correctly and simply uses a hardcoded value. Next thing to you, your data is being screwed with by an unknown app.
You'd probably be better off using a file based system that stores data in/tmp/phppersistant or something, and uses file locking to control access. Of course, you'd need to write it all yourself since I don't know of any existing class to perform this. Even then, nothing comes close to a native solution within PHP itself for speed and reliability. If it's so easy using shared memory, why isn't there already a built in solution using this that is part of the default compile? I'd guess that portability of PHP probably makes this solution useless. Last I checked, SysV IPC wasn't available on Wintel boxes. Sure, the functionality is duplicated within different API calls, but it really isn't SysV IPC.
Don't want to sound demeaning, but I just don't see the practicality of using shared memory for something that should already be included natively. *shrug*
Slashdotting occurs mainly because 1 of 2 things happens. Either a) the pipe to the webserver is too small and the traffic overwhelms their connection; or b) the hardware falls behind in servicing the requests, and thus pages start failing.
Usually, it's b). Particularly, database queries being the main culprit. When people write database backended websites, they take 1 of two approaches. Make calls to the database every time a page is requested (most used), or they call the database for the first request, caching the result, and feed the cached copy to all other requests that occur within the cache's lifetime.
Method 1 is easier to do, but is flawed, in that you are placing all of the load on the database server. Once the requests start to pile up, it immediately becomes a bottleneck.
There was a nice write up about how some group put together a slashdot proof system, consisting of only modest Sun hardware. Their key was the use of java to run the website. Java allowed them to create system-wide objects that could be referenced by unrelated page requests. So they took method 2 in website design, and had a system that only made calls to the database when the cache didn't already hold a requested page.
PHP4 (and 3), unfortunately, do not allow for persistant system-wide objects. Not even lowly variables. So you can pretty much bet that any stock webserver using PHP will not handle a slashdot link on it's own. It would need a caching server to keep the requests to the database at a minimum. Hopefully, PHP5 will fix this little problem, as even ASP allows for system-wide objects.
So the short answer to your last question is: It is the fault of the programmer for choosing the wrong model, but PHP doesn't give them any other option, making their only alternative to use a different language.
As per usual, Mandrake has completely ignored the Gnome specs for menu layout, and have a completely non-standard menu system. All I can say is Ick, I'll wait 5 more days for RH 9 thanks.:(
He's not questioning his legal right to use the clips as he is, you're right in that the DMCA does not cover this. However, the DMCA does prevent him from legally unencoding the DVD streams to generate the clips that he's using. The DMCA also covers the creation of the clips, even if the DVD is not encoded, since creating DivX clips of various scenes is not one of the original manufacturer intended uses.
In other words, the clips themselves are not in question, it is the method in which he's obtained them.
His legal alternative? Request the clips from the studio already in DivX format, for consumption by his class.
Likelyness that he'd ever see a response from the studio? nil
Realistically, X11 is pretty fukt. It is horribly slow. Horribly horribly slow. The only thing that makes it usable are the extensions crammed into it. Xv, freetype, Xrender, etc...
Yet we are at an impass. Half of the Unix population loves X for the network transparency, the other half could care less and just want it to draw fast and look nice.
IMHO, we need to ditch XFree completely. Don't ditch the X protocol, just ditch XFree. If we could get a system that supported nice modular drivers, had lightning fast redraws and event handling, and yet still had legacy support for apps using X11, then we'd have something worth using.
Personally, I'm not that impressed by X's network transparency. Sure, I can run an app over the network, but a) I better have all the right fonts; and b) I better hope my system doesn't hang or lose my net connection, because if my system stops responding to all of those X packets, the app on the remote system is killed. I'd be happier to see a clean session detach that could reattached at my leisure. Automatic font transfer would be nice too. Don't have a font installed locally? No problem! I'll just auto install it for your user account.
But, regardless of my bitching, we don't have MagicDisplay(tm) right now. We have X. And being that I use linux as my desktop system, I'm greatful to the XFree team for getting us this far.
From a technology standpoint, MySQL is indeed quite lacking. However, from a usability standpoint, MySQL is absolutlely fabulous. The installation is incredibly easy, whether you use the prebuilt static binaries, compile from source, or use the packages that come with your Linux distro. And using the application is simple as well. Not to mention that the documentation for MySQL is superb.
But in the end, you are correct. MySQL doesn't scale to enterprise levels because of the lacking feature set. It is perfect for websites and as a storage medium for certain applications, and that is really about it. There's nothing wrong with being a niche product, and MySQL fits its niche perfectly.
Actually, this is an interesting point, but it isn't as valid as you make it out to be. There is absolutely no good reason to embed an RDBMS into an operating system. Not at the level that you are referring to anyways. If you mean filesystem attributes, then that is a different fish, but making a database part of an OS is a bit much.
XML and flat files are good for data that does't change very often, and are only ever edited by a single user. (XML is also a good way to feed data fram a database into an application) Beyond that, they are pretty useless. They require far too much time on the developer's part when data within given contraints are needed, and coordinating updates between multiple processes can easily turn into a nightmare. Not to mention scalability. XML can get pretty large, and due to the non-indexed nature of the data, it can take a long time to read through it all looking for what you need. For many applications, using a database just makes sense.
The whole point of an app using a database is to offload the storage specifics onto another program. I applaude the developers of these "MySQL (ab)using programs" for making the decision to focus on their products features and stability, rather than on how they will store their records. Besides, once you install MySQL (or Postgres) once, then it is there for all of your DB dependant apps to use.
Not to mention the fact that MySQL 4 has standalone features that make your argument pretty moot. Any application can link in the MySQL core at build time, and will be able to have it's own MySQL databases separate from any active system wide MySQL instance. This gives developers an SQL storage system, without requiring the user to install a database on their own. It just comes bundled with the app, and when the app loads, the MySQL core is loaded right along with it.
I'll keep using databases for storage, and flat files for configuration data, thanks though!;)
Actually, I've read in several Win32API books that DLLs are the only way to get direct access to hardware.
Now I never said anything about security contexts. You are absolutely correct in the regard that calling to DLLs doesn't mean you get a new security context.
But you're also wrong. At least in explaination. A DLL technically has no security context. Security contexts are bound to processes, not DLLs. If a process makes a call to a DLL function, that routine runs with the process's security context. Even if the DLL was initially loaded because a different user's process called for it first. I'm pretty sure that what you were thinking at the time was correct, but you weren't very clear when you said it. Figured I'd clear it up for the ppl who aren't so sure.:)
The security I was referring to was purely about hardware access. I probably should have worded that differently. So I'm partly at fault as well. Anyways, we're both right and both wrong. Kind of funny, that usually doesn't happen.:)
Each static library you use in your code adds to the overall program size, as you've stated. Thus increasing load time when you run the app. A 4MB exe loads a lot faster than a 400MB exe. (At least when the bulk of the difference is actual code/runtime-data, rather than generic data tacked on to the end of the file.) When you have DLLs, the OS will reuse already loaded DLLs for your app, and will keep newly loaded DLLs in memory for a while even after the app shuts down. This tremendously speeds up application loading.
Plus it allows for version upgrades in the DLLs without requiring recompiles of the applications. Of course, this feature really isn't used in Windows, since MS can't seem to make an application run according to specs, most developers work around and sometimes even depend on the bugs that are in MS's code. Thus creating DLL version dependant apps. If MS goes back and fixes the broken DLLs, they will break a bunch of third party apps in the process. Probably some of their own as well.
Plus their is security. Applications do not have the same level of access as DLLs. In fact, if you want to do some low level hardware access in Windows, you MUST use a DLL as a thunking layer, since you can't access the hardware from code within a regular process.
There are other reasons, but I'm getting lazy, so I'll let someone else finish if they feel like it is needed.
In short, there are plenty of reasons to use dynamically loaded libraries. But the generally poor coding practices that occur on the Windows platform pretty much ruins almost all of them. It's actually pretty sad. Windows had a lot of potential to become a great OS. Too many fuck ups and shortcuts have wrecked that chance. Fixing it would require an entirely new code base. One that doesn't have native ABI support for old apps. Which, of course, MS will never do. At least there's open source software to do things right.:)
It's called SYN flooding. The idea is that a system only has so much memory to work with. Each established TCP session has memory overhead for packet ordering and split packet reassembly. Generally, when a system recienves a SYN packet, it assumes that the session is going to be valid, and it begins the process of completing the TCP session building, which happens to include setting aside some memory for session management.
For each SYN packet you send, you eat up a little bit more memory and CPU time on the victim. Do it enough times, and the system runs out of memory or processor time, and the system becomes unable to perform its regular operations. Effectively causing a Denial of Service.
If you're smart, you'll form the SYN packets to have source addresses that differ from your real IP, otherwise a) you're traceable; and b) your machine will be flooded with SYN/ACKS. If you are even smarter, you'll use an IP that, while valid and routable, belongs to a host that either doesn't exist, or is currently off. Otherwise the 2nd level victim recieving the SYN/ACKs from your initial target will send RSETs for every SYN/ACK, since it never requested to initial the connection. When your target gets the RSET for the SYN/ACK, it will close the session, freeing up the memory and CPU time that you are desparately trying to fill. Essentially, a non-existant host will never respond to a SYN/ACK, so the target system has to wait for a timeout duration before closing the session, which makes it easier for you to eat up CPU and memory. Unfortunately though, the fake spirce IP on your SYN packets will likely have to be within your ISP's network range, as all smart ISP network administrators perform egress packet filtering to prevent such attacks from originating within their network.
Better tactics include sending the SYNs from multiple machines that have different providers. Thus preventing load from the SYN/ACKs from filling your ISPs pipe. This effectively makes the attack a DDoS, rather than a DoS.
Either way, you can't really perform these attacks in much safety, as competent network administrators will have sniffers in place to detect these attacks as they cross their network. So #1) if your ISP admin is smart, you're busted by them regardless; and #2) if the chain of smart admins follows you all the way back to your sources, you're busted by the authorities (which if you cross state lines means the Feds, which will suck quite adamently).
So, that is how it works, but I wouldn't recommend trying it.
Seems to me that this could really help broadband providers supply a better service if this was implemented in the firmware of the modems and the headend equipment.
Then again, since when have most broadband providers really ever cared about supplying good speeds when the user maxes out the outrageously capped upstream...
I don't think we really need to worry about that problem. We'll just replace all of those natural resources we take from the moon with the best mass replacing substitute we Earthlings can produce. 100% pure nonbiodegradable garbage!:)
Take up a load of garbage, come back with moon stuffs. It's perfect! heh
No shit. D_Gr8_BoB has a pretty weak argument against NFS. So some dumshit deletes his loopback mounted filesystem, and then he blames NFS for the flakyness that ensues?
This is why we don't mount important things in loopback mounts. This is also why we change root passwords on a weekly basis and rule who does and does not have root access with an iron fist. This isn't NFS's fault, this is poor system management. I sure hope the lost data was nothing but scratch space, because if it wasn't and he worked where I do, he'd be fired.
Last I checked, Sun's licensing model was such that any Sun brand SPARC based system was already licensed for Solaris. That was true for (2.)7 and (2.)8. There is an enterprise version as well that had a few extra bells and whistles that you had to pay for, but at heart it was still the same Solaris base. It just had some extra trimmings that could be installed from the same media set.
So... how does changing from a cpu based (free for all Sun SPARC systems) model to a subscription model generate more revenue? If the product is already essentially free, why would you want to start paying for it?
Keep in mind that I'm not up to snuff on Solaris 9's licensing (though as a Sun Cert'ed Network Admin I probably should fix that;P)
What is with the obsession of finding solutions to earth/asteroid collisions? Statistically, nothing has changed between now and 300,000 years ago, and we haven't had a planet-killer impact in that long. In fact, as time goes by our odds of not getting hit only get better, as Jupiter and the Sun keep sucking up more loose asteroids in our system.
We would be better off throwing the 150 million at furthering our space travel technology. At least that way we'll be much better prepared for when a true planet killer comes along. We'd have the option to jump ship if our redirecting efforts did not work. (And let's face it, if we were going to be struck with a 500 mile wide chunk of nickel from space, we sure as hell can't expect to blow it up with nukes. Redirecting is our ONLY real chance to prevent disaster.)
Besides, once we have space trasport down to a trivial science, we'll have regular patrols to scout for crap like this. And it will be on a budget that won't kill our wallets...
How exactly are you supposed to stay on top of this? Re-test the system for every previous vulnerability after every single patch?
Actually, yes. This is called regression testing, and it's pretty common in the software industry. Not only are security holes quite often the result of a bug, but their behavior is quite similar to a bug. Either it is fixed, or it isn't. The same script kiddie code won't affect a successfully fixed security hole, even if the fix opens up a new hole, the old one is fixed. Because the regression test also checks previous holes, you can be assured that the fix hasn't reopened any of them.
As for the manpower problem, there are regression testing suites available that cut the manpower down to nearly nothing. Your manpower argument could be applied to Linux just as easily. The kernel has too much code and too many contributers, it will never work. But at the end of the day, if Linus runs 'make' and your bug-fix fails, then your code is fucked and gets rolled back, end of story.
On the other hand, I do agree with your last paragraph. MS has dug themselves a pretty deep hole. It will take years of code auditing to really fix the problem. By then, the next version of Windows will be out, and all their efforts wil have been wasted. They are honestly better off just focusing all of their newfound security awareness into their next product lines, and continuing to make the less-then-stellar patches we're used to for their current products. Oh well, guess you can't have your cake and eat it to. *shrug*
For the record, my little test was successful. I moved a 3.7GB file across NFS between Linux boxes. Filesizes and md5sums match between the original and the NFS copy. The source and destination were both running RedHat 8, though Linux has used the NFS ver3 for quite a while now. Definitely as of the 2.2 kernel, probably back into the 1.x series even.
I will agree with you, Sun really has their act together when it comes to making a good commercial Unix. They have nice hardware, and their OS is pretty solid. They have a few memory leaks in some libraries (as of 2.8), but nothing that can't be worked around, and most applications that care take the bugs into account. Of course, Sun has been in the biz for quite a while.;)
Anyhow, always nice chatting with fellow Slowaris er..Solaris junkie.;)
Slashdot Mirror
I agree. Right now my home system is getting ~22kB/s down, ~3kB/s up. (I forced an upload cap to prevent saturation, I have eDonkey running @10kB/s up too ;)
:)
Long story short, the now estimated 20 hour download is much better than the alternative. I'm running RedHat 8 right now. I'm kind of anxious to see what is new in 9. I'll probably spin over to redhat.com sometime today to see what all the fuss is about. Maybe they're finally LSB compliant.
Gotta love it. 29KBps upstream, 0 KBps downstream, and I only have a few bytes worth of valid data. Oh yeah, she scales real well. Hehe. Oh well. 78hours is still sooner than 1 week + fight for FTP time. I should probably restart with an upload cap though. My poor 256k sync here at work isn't liking the flooded upstream too much. ;)
My dad wrote some CNC control software that would work quite well for this application. It's designed to run anything from table top machines (such as this) all the way up to large scale CNC retrofits, where the iron is good but the control is shot. Very competitively priced as well. Even has a free demo version with no time limit for those that want to check it out. Requires a dos based machine to run it on though. FreeDOS works fine, of course so does MS-DOS.
:)
I'm sure this will kill his pipe, but here is a link: www.cnczeus.com
It's listed in google as well, so you may want to check that out if/when the pipe goes dead from the load.
why do you think that ip6 is going to remove the necessity of NAT? I've seen several network installations that use 1-to-1 NAT. This configuration does not cause anywhere near the number of problems that you are thinking of. I can even think of one site that used 1-to-1 NAT twice on the same network block. Once to go from public IP to a private range, and then on the other side of the network another router did 1-to-1 NAT back to the packets' original IP.
Not to mention that many users of consumer level NATing devices (Cable/DSL routers) do so for financial reasons, not out of necessity. Why pay your ISP for another IP address when you can run upwards of 200 machines on the one you already have.
My spouse works for the cable co, so I get free cable modem service, but I only have 1 IP because I'd rather not play the dhcp game with every machine on my home network, praying that they stay within the same subnet so they can talk to eachother directly. Plus, I don't like the idea of all of my local traffic being bridged to the NOC just because the modem firmware doesn't know any better.
Nice small form factor, like Mini-ITX.
1 AGP slot, 2 PCI slots
Onboard LAN
AthlonXP supporting chipset
2GB max ram
This way, I have onboard lan, can choose my own video card, choose my own sound card, and still have another slot left incase the onboard lan dies, or incase i need a modem for dialup.
I haven't looked very hard, but most mini-itx boards i see have onboard video and sound, which pretty much sucks for anyone planning on doing anymore more than word processing.
sorry about the 2nd thread, but I figured you wouldn't see this unless I posted this way.
:)
After sleeping on it, I thought of another reason why shared memory doesn't work. Objects that have filehandle references won't correctly persist, since the stream is closed when the php instance shuts down.
A good example of why this is important is dabatase connection pooling. I've worked on a few large commercial websites, written in ASP, backended by Oracle. The system was already existing when I got there, I just helped make a few updates. The interesting part is that the pages were written to share a single database connection that persisted between requests. With a cluster of 25 webservers, and a few million hits a day, it was important to keep the database connections persistant to reduce the connect/disconnect load on Oracle. Instead of having to authenticate over a million connections a day, the Oracle DB was only required to authenticate a webserver on the first request served. The allowed the database to focus on serving out the required data, rather than fussing about opening and closing sockets all day long.
Anyhow, just thought I would bring that up.
Unfortunately, there are issues with using shared memory that would be better off handled by PHP itself. The integer keys need to be unique, which can be a bit of a pain to generate in the first place, but also lead to issues if other software isn't written correctly and simply uses a hardcoded value. Next thing to you, your data is being screwed with by an unknown app.
/tmp/phppersistant or something, and uses file locking to control access. Of course, you'd need to write it all yourself since I don't know of any existing class to perform this. Even then, nothing comes close to a native solution within PHP itself for speed and reliability. If it's so easy using shared memory, why isn't there already a built in solution using this that is part of the default compile? I'd guess that portability of PHP probably makes this solution useless. Last I checked, SysV IPC wasn't available on Wintel boxes. Sure, the functionality is duplicated within different API calls, but it really isn't SysV IPC.
You'd probably be better off using a file based system that stores data in
Don't want to sound demeaning, but I just don't see the practicality of using shared memory for something that should already be included natively. *shrug*
Slashdotting occurs mainly because 1 of 2 things happens. Either a) the pipe to the webserver is too small and the traffic overwhelms their connection; or b) the hardware falls behind in servicing the requests, and thus pages start failing.
:)
Usually, it's b). Particularly, database queries being the main culprit. When people write database backended websites, they take 1 of two approaches. Make calls to the database every time a page is requested (most used), or they call the database for the first request, caching the result, and feed the cached copy to all other requests that occur within the cache's lifetime.
Method 1 is easier to do, but is flawed, in that you are placing all of the load on the database server. Once the requests start to pile up, it immediately becomes a bottleneck.
There was a nice write up about how some group put together a slashdot proof system, consisting of only modest Sun hardware. Their key was the use of java to run the website. Java allowed them to create system-wide objects that could be referenced by unrelated page requests. So they took method 2 in website design, and had a system that only made calls to the database when the cache didn't already hold a requested page.
PHP4 (and 3), unfortunately, do not allow for persistant system-wide objects. Not even lowly variables. So you can pretty much bet that any stock webserver using PHP will not handle a slashdot link on it's own. It would need a caching server to keep the requests to the database at a minimum. Hopefully, PHP5 will fix this little problem, as even ASP allows for system-wide objects.
So the short answer to your last question is: It is the fault of the programmer for choosing the wrong model, but PHP doesn't give them any other option, making their only alternative to use a different language.
Hope that helps.
As per usual, Mandrake has completely ignored the Gnome specs for menu layout, and have a completely non-standard menu system. All I can say is Ick, I'll wait 5 more days for RH 9 thanks. :(
He's not questioning his legal right to use the clips as he is, you're right in that the DMCA does not cover this. However, the DMCA does prevent him from legally unencoding the DVD streams to generate the clips that he's using. The DMCA also covers the creation of the clips, even if the DVD is not encoded, since creating DivX clips of various scenes is not one of the original manufacturer intended uses.
In other words, the clips themselves are not in question, it is the method in which he's obtained them.
His legal alternative? Request the clips from the studio already in DivX format, for consumption by his class.
Likelyness that he'd ever see a response from the studio? nil
Realistically, X11 is pretty fukt. It is horribly slow. Horribly horribly slow. The only thing that makes it usable are the extensions crammed into it. Xv, freetype, Xrender, etc...
Yet we are at an impass. Half of the Unix population loves X for the network transparency, the other half could care less and just want it to draw fast and look nice.
IMHO, we need to ditch XFree completely. Don't ditch the X protocol, just ditch XFree. If we could get a system that supported nice modular drivers, had lightning fast redraws and event handling, and yet still had legacy support for apps using X11, then we'd have something worth using.
Personally, I'm not that impressed by X's network transparency. Sure, I can run an app over the network, but a) I better have all the right fonts; and b) I better hope my system doesn't hang or lose my net connection, because if my system stops responding to all of those X packets, the app on the remote system is killed. I'd be happier to see a clean session detach that could reattached at my leisure. Automatic font transfer would be nice too. Don't have a font installed locally? No problem! I'll just auto install it for your user account.
But, regardless of my bitching, we don't have MagicDisplay(tm) right now. We have X. And being that I use linux as my desktop system, I'm greatful to the XFree team for getting us this far.
+/-50%
*grin*
From a technology standpoint, MySQL is indeed quite lacking. However, from a usability standpoint, MySQL is absolutlely fabulous. The installation is incredibly easy, whether you use the prebuilt static binaries, compile from source, or use the packages that come with your Linux distro. And using the application is simple as well. Not to mention that the documentation for MySQL is superb.
But in the end, you are correct. MySQL doesn't scale to enterprise levels because of the lacking feature set. It is perfect for websites and as a storage medium for certain applications, and that is really about it. There's nothing wrong with being a niche product, and MySQL fits its niche perfectly.
Actually, this is an interesting point, but it isn't as valid as you make it out to be. There is absolutely no good reason to embed an RDBMS into an operating system. Not at the level that you are referring to anyways. If you mean filesystem attributes, then that is a different fish, but making a database part of an OS is a bit much.
;)
XML and flat files are good for data that does't change very often, and are only ever edited by a single user. (XML is also a good way to feed data fram a database into an application) Beyond that, they are pretty useless. They require far too much time on the developer's part when data within given contraints are needed, and coordinating updates between multiple processes can easily turn into a nightmare. Not to mention scalability. XML can get pretty large, and due to the non-indexed nature of the data, it can take a long time to read through it all looking for what you need. For many applications, using a database just makes sense.
The whole point of an app using a database is to offload the storage specifics onto another program. I applaude the developers of these "MySQL (ab)using programs" for making the decision to focus on their products features and stability, rather than on how they will store their records. Besides, once you install MySQL (or Postgres) once, then it is there for all of your DB dependant apps to use.
Not to mention the fact that MySQL 4 has standalone features that make your argument pretty moot. Any application can link in the MySQL core at build time, and will be able to have it's own MySQL databases separate from any active system wide MySQL instance. This gives developers an SQL storage system, without requiring the user to install a database on their own. It just comes bundled with the app, and when the app loads, the MySQL core is loaded right along with it.
I'll keep using databases for storage, and flat files for configuration data, thanks though!
Actually, I've read in several Win32API books that DLLs are the only way to get direct access to hardware.
:)
:)
Now I never said anything about security contexts. You are absolutely correct in the regard that calling to DLLs doesn't mean you get a new security context.
But you're also wrong. At least in explaination. A DLL technically has no security context. Security contexts are bound to processes, not DLLs. If a process makes a call to a DLL function, that routine runs with the process's security context. Even if the DLL was initially loaded because a different user's process called for it first. I'm pretty sure that what you were thinking at the time was correct, but you weren't very clear when you said it. Figured I'd clear it up for the ppl who aren't so sure.
The security I was referring to was purely about hardware access. I probably should have worded that differently. So I'm partly at fault as well. Anyways, we're both right and both wrong. Kind of funny, that usually doesn't happen.
Plenty.
:)
Each static library you use in your code adds to the overall program size, as you've stated. Thus increasing load time when you run the app. A 4MB exe loads a lot faster than a 400MB exe. (At least when the bulk of the difference is actual code/runtime-data, rather than generic data tacked on to the end of the file.) When you have DLLs, the OS will reuse already loaded DLLs for your app, and will keep newly loaded DLLs in memory for a while even after the app shuts down. This tremendously speeds up application loading.
Plus it allows for version upgrades in the DLLs without requiring recompiles of the applications. Of course, this feature really isn't used in Windows, since MS can't seem to make an application run according to specs, most developers work around and sometimes even depend on the bugs that are in MS's code. Thus creating DLL version dependant apps. If MS goes back and fixes the broken DLLs, they will break a bunch of third party apps in the process. Probably some of their own as well.
Plus their is security. Applications do not have the same level of access as DLLs. In fact, if you want to do some low level hardware access in Windows, you MUST use a DLL as a thunking layer, since you can't access the hardware from code within a regular process.
There are other reasons, but I'm getting lazy, so I'll let someone else finish if they feel like it is needed.
In short, there are plenty of reasons to use dynamically loaded libraries. But the generally poor coding practices that occur on the Windows platform pretty much ruins almost all of them. It's actually pretty sad. Windows had a lot of potential to become a great OS. Too many fuck ups and shortcuts have wrecked that chance. Fixing it would require an entirely new code base. One that doesn't have native ABI support for old apps. Which, of course, MS will never do. At least there's open source software to do things right.
It's called SYN flooding. The idea is that a system only has so much memory to work with. Each established TCP session has memory overhead for packet ordering and split packet reassembly. Generally, when a system recienves a SYN packet, it assumes that the session is going to be valid, and it begins the process of completing the TCP session building, which happens to include setting aside some memory for session management.
For each SYN packet you send, you eat up a little bit more memory and CPU time on the victim. Do it enough times, and the system runs out of memory or processor time, and the system becomes unable to perform its regular operations. Effectively causing a Denial of Service.
If you're smart, you'll form the SYN packets to have source addresses that differ from your real IP, otherwise a) you're traceable; and b) your machine will be flooded with SYN/ACKS. If you are even smarter, you'll use an IP that, while valid and routable, belongs to a host that either doesn't exist, or is currently off. Otherwise the 2nd level victim recieving the SYN/ACKs from your initial target will send RSETs for every SYN/ACK, since it never requested to initial the connection. When your target gets the RSET for the SYN/ACK, it will close the session, freeing up the memory and CPU time that you are desparately trying to fill. Essentially, a non-existant host will never respond to a SYN/ACK, so the target system has to wait for a timeout duration before closing the session, which makes it easier for you to eat up CPU and memory. Unfortunately though, the fake spirce IP on your SYN packets will likely have to be within your ISP's network range, as all smart ISP network administrators perform egress packet filtering to prevent such attacks from originating within their network.
Better tactics include sending the SYNs from multiple machines that have different providers. Thus preventing load from the SYN/ACKs from filling your ISPs pipe. This effectively makes the attack a DDoS, rather than a DoS.
Either way, you can't really perform these attacks in much safety, as competent network administrators will have sniffers in place to detect these attacks as they cross their network. So #1) if your ISP admin is smart, you're busted by them regardless; and #2) if the chain of smart admins follows you all the way back to your sources, you're busted by the authorities (which if you cross state lines means the Feds, which will suck quite adamently).
So, that is how it works, but I wouldn't recommend trying it.
Seems to me that this could really help broadband providers supply a better service if this was implemented in the firmware of the modems and the headend equipment.
Then again, since when have most broadband providers really ever cared about supplying good speeds when the user maxes out the outrageously capped upstream...
I don't think we really need to worry about that problem. We'll just replace all of those natural resources we take from the moon with the best mass replacing substitute we Earthlings can produce. 100% pure nonbiodegradable garbage! :)
Take up a load of garbage, come back with moon stuffs. It's perfect! heh
No shit. D_Gr8_BoB has a pretty weak argument against NFS. So some dumshit deletes his loopback mounted filesystem, and then he blames NFS for the flakyness that ensues?
This is why we don't mount important things in loopback mounts. This is also why we change root passwords on a weekly basis and rule who does and does not have root access with an iron fist. This isn't NFS's fault, this is poor system management. I sure hope the lost data was nothing but scratch space, because if it wasn't and he worked where I do, he'd be fired.
Last I checked, Sun's licensing model was such that any Sun brand SPARC based system was already licensed for Solaris. That was true for (2.)7 and (2.)8. There is an enterprise version as well that had a few extra bells and whistles that you had to pay for, but at heart it was still the same Solaris base. It just had some extra trimmings that could be installed from the same media set.
;P)
So... how does changing from a cpu based (free for all Sun SPARC systems) model to a subscription model generate more revenue? If the product is already essentially free, why would you want to start paying for it?
Keep in mind that I'm not up to snuff on Solaris 9's licensing (though as a Sun Cert'ed Network Admin I probably should fix that
ah well, don't mind me, just burning karma
What is with the obsession of finding solutions to earth/asteroid collisions? Statistically, nothing has changed between now and 300,000 years ago, and we haven't had a planet-killer impact in that long. In fact, as time goes by our odds of not getting hit only get better, as Jupiter and the Sun keep sucking up more loose asteroids in our system.
We would be better off throwing the 150 million at furthering our space travel technology. At least that way we'll be much better prepared for when a true planet killer comes along. We'd have the option to jump ship if our redirecting efforts did not work. (And let's face it, if we were going to be struck with a 500 mile wide chunk of nickel from space, we sure as hell can't expect to blow it up with nukes. Redirecting is our ONLY real chance to prevent disaster.)
Besides, once we have space trasport down to a trivial science, we'll have regular patrols to scout for crap like this. And it will be on a budget that won't kill our wallets...
At least until you see the price tag that comes with it vs. conventional panels. ;)
Actually, yes. This is called regression testing, and it's pretty common in the software industry. Not only are security holes quite often the result of a bug, but their behavior is quite similar to a bug. Either it is fixed, or it isn't. The same script kiddie code won't affect a successfully fixed security hole, even if the fix opens up a new hole, the old one is fixed. Because the regression test also checks previous holes, you can be assured that the fix hasn't reopened any of them.
As for the manpower problem, there are regression testing suites available that cut the manpower down to nearly nothing. Your manpower argument could be applied to Linux just as easily. The kernel has too much code and too many contributers, it will never work. But at the end of the day, if Linus runs 'make' and your bug-fix fails, then your code is fucked and gets rolled back, end of story.
On the other hand, I do agree with your last paragraph. MS has dug themselves a pretty deep hole. It will take years of code auditing to really fix the problem. By then, the next version of Windows will be out, and all their efforts wil have been wasted. They are honestly better off just focusing all of their newfound security awareness into their next product lines, and continuing to make the less-then-stellar patches we're used to for their current products. Oh well, guess you can't have your cake and eat it to. *shrug*
For the record, my little test was successful. I moved a 3.7GB file across NFS between Linux boxes. Filesizes and md5sums match between the original and the NFS copy. The source and destination were both running RedHat 8, though Linux has used the NFS ver3 for quite a while now. Definitely as of the 2.2 kernel, probably back into the 1.x series even.
;)
;)
I will agree with you, Sun really has their act together when it comes to making a good commercial Unix. They have nice hardware, and their OS is pretty solid. They have a few memory leaks in some libraries (as of 2.8), but nothing that can't be worked around, and most applications that care take the bugs into account. Of course, Sun has been in the biz for quite a while.
Anyhow, always nice chatting with fellow Slowaris er..Solaris junkie.
Cheers!