You are definitely correct that proper design is the way to go. I would never argue against that. However, my original point is that there are certain problems that are better solved by stored procedures. If you can avoid sending out a several dozen MB each time a query is run by spending an extra second on the database server to do some additional processing, and if it supports your business goals, I would say that is a situation that could benefit from stored procedures.
And quickly, as for your last comment, I also agree. Overuse of any feature is not a good thing -- even if it's a feature you like. You might be surprised since it may seem that I am advocating the use of stored procedures more than you may like, but I have not used a single one in the past year in any of my applications (which support tens of thousands of users each day and are mission critical for our business). Why? They weren't appropriate solutions to any of the problems.
What I am arguing against is the notion from some people that stored procedures are *never* needed because they can be "emulated" in the client layer which is untrue.
That would alleviate some of the problems, but it does not solve all of them, and it even introduces new ones.
What it does solve is the deployment problem of updating hundreds of client applications. You would only need to update this intermediary server that sits in between the clients and the database.
What it does not solve is the fact that you will still have to transfer all data from the database server to another machine before you do any work on the data. And you still need to allocate effectively twice as much memory as you would if you just kept the data on the database server and used stored procedures when appropriate.
However, here are just a few of the new problems your solution introduces:
Your clients no longer just connect to a database server. They're connecting to a piece of middleware which will broker all connections. This can be an advantage for some types of applications, but it is more difficult to implement and could very well increase your code base significantly. Not to mention, if your programmers don't have the experience implementing solid middleware solutions, your setup could be very inefficient.
What about all the database queries that don't need the stored procedures? Your solution gives two options. a) Each client maintains one connection to the database server directly and one connection to the middleware server. b) All requests go through the middleware. The first option introduces new complexities in to the code, and puts more of the responsibility for deciding when to query the database and when to use a stored procedure on the software developers, not the database designers. In general, that is not a good thing, unless your programmers are also DBAs (or equivalent/better knowledge).
The second option is terribly inefficient. You now have to transfer all the data from the database server to the middleware, then from the middleware to the client. At least twice as much traffic as you should be generating for cases where the middleware didn't actually need to do anything to the data itself.
I'm not saying that middleware is inherently bad. It is a very appropriate (if not exclusive) solution for many problems. But, to say that you don't need stored procedures because "we can stick another server in between the clients and the database" is a very poor solution.
Your statement shows you don't understand the real benefits of stored procedures. Say you have a very common task that, unfortunately, needs to work on a large set of data, but consistently results in only a few rows of data when it has finished going through all the data. Now, which of the following two options is better:
1. The original large set of data (say, 10MB) is transferred over the network to the front end machine which then runs through it's motions and trims that dataset down to the final 8KB of data actually needed. Aside from the IO, both machines need to reserve 10MB of memory to store the data set, plus additional memory for intermediary data structures while the code works.
2. The original 10MB of data stays on the database server, never being sent over the network to the front end machine. The stored procedure works on the original data culled from the database, does it's magic, and then transfers the final 8KB worth of data over the network to the front end machine. While the database server still needs to allocate 10MB for the dataset plus memory for intermediary data structures, the front end machines only has to allocate 8KB of memory for the final results -- plus, 10MB of data never needed to be transferred over the network.
If you answered #2, you've just given one example of why stored procedures can be a far better way to handle certain problems. They're no panacea, but "emulating" stored procedures in your front end application is a horrible way to justify not providing stored procedures in a database server.
If that example wasn't enough for you, consider the following.
You have an enterprise department consisting of a few hundred employees all running a GUI application which connects to a database to allow access to financial/customer/product/whatever data to all the employees. Various inquires in to the data need to compute values, collate data, or perform other complex operations on tens of thousands of ledger entries/customer accounts/products/whatevers.
Now, choose one of these two options:
1. You embed all, and I mean all (since you don't have stored procedures), logic relating to these inquiries in to the GUI application. You then update each workstation with the new version of the client to support the changes. This involves rolling out the new version to hundreds of machines, causing worker downtime for each machine (or a few very late nights and expensive overtime for your IT staff). Then you find out a few days later that your QA staff didn't catch a very problematic bug that affects half the staff. It turns out the bug was very easy to fix, but you now have to redeploy the updated application to the hundreds of machines -- again.
2. Your GUI application does not contain any of the logic relating to munging/collating/etc. the data in question. These are contained as stored procedures inside the database server. Your client application, installed on hundreds of machines, simply call this procedure on the database. You update the stored procedure and instantly all clients are now using the new version. A couple days later, you find out QA didn't find a problematic bug. Turns out, it was easy to fix, and in minutes all of the hundreds of machines now use the fixed version of the procedure.
As my last example, how exactly do you propose to be able to create effective triggers without some form of a stored procedure? Triggers are a wonderful feature (also lacking in MySQL) that go hand in hand with stored procedures. But, I've already been long winded enough in this post, so I'll wrap up.
Are you starting to get the picture? If stored procedures weren't so useful, nobody would want them. The real problem is that people who don't understand databases or database application design *think* that stored procedures can always be effectively "emulated" in the client layer, and so they *think* that stored procedures aren't useful.
You're correct, the submitter was an idiot. Xinerama has absolutely nothing to do with movies and everything to do with connecting multiple monitors to a single box.
Xinerama is not necessary for multi-head setups. However, without it each monitor is a separate screen (i.e.:0.0,:0.1, etc.) and you cannot move windows between them. With Xinerama, you can make them act as a single display, allowing you to run only one instance of your window manager and drag windows between them.
But, there is a downside. Hardware accelerated OpenGL for most video cards does not cooperate with Xinerama. I've been sort of waiting ever since XFree86 4.0 came out for nVidia to find a way around this in their drivers so that I can get away from software OpenGL rendering. I'm not holding my breath, though, as I imagine that splitting a single OpenGL scene at an arbitrary point across two completely separate devices is a tricky thing to handle very well.
The OpenGL problem aside, having several LCD screens all lined up next to each other is a Nice Thing. Just tell your boss you're more productive with such a setup -- I am honestly more productive being able to spread my work out over a wall of screens. I just run out of PCI slots real fast.;)
As for 12 IDE devices anyone know of a case that can cram that much into it?!
The two boxes sitting underneath the networking equipment in our network/server closet here at work. Sure, they're more expensive cube cases, but one actually has twelve drives in it. Linux and software RAID turns them in a great half terabyte (non-mission-critical) fileserver for the office.
Back in the days that I worked at a small ISP (there were five of us that ran the place, including all the dialup, colo and virtual hosting) I would actually keep a tail running on a separate screen for our radius logs. It provided me with early warning for when I would have to hide and get that chat icon above my character's head in Quake so that I could answer a call from a user who forgot their username or password.
Do *not* learn the actual query language first. Learn database theory and design before anything else. Don't even consider doing anything with a database until you know the six forms of normalization (at a bare minimum you need to know the first three; the second three are "gravy" for many applications and not even appropriate all the time). This includes knowing the requirements to reach each level of normalization within a database.
I have seen so many database layouts for various applications that have practically brought me to tears through their sheer stupidity. These were layouts designed purportedly by people who "knew SQL." There is a tremendous difference between "knowing SQL" and "knowing proper database design and implementation." Unfortunately, many people who claim to be database programmers do not realize there is a difference and assume that since they know the syntax of SQL, they know how to design a database.
I would recommend that you begin with "Database Systems" by Connolly and Begg. Read it cover to cover, then read it again. When you're done reading it the second time, skip through to the end of each section and do all the exercises without rereading any of the text. Once you can answer a majority of the questions correctly, then begin to consider designing database layouts. Before you look the book up on fatbrain or amazon, be warned that it is not light reading. It's 1,200+ pages, but is well worth it.
The ISBN is: 0201708574.
When you actually understand how databases work and how to effectively use them, you will thank yourself tremendously for taking the time up front. If you dive right in to learning the syntax of the query language without understanding the basics of design and implementation, you will make one stupid mistake after another with no end in sight. Then, someone more knowledgeable than yourself will come along and will have to start everything over from scratch to fix your screwups.
Doing it right the first time is especially important when designing databases for large systems. If you screw something up and don't learn from your mistake until you have millions of records in tables that are being quickly updated 24/7, fixing that mistake is going to be a nightmare and could very well cost your company a tremendous amount of money through downtime and resources spent on the fix and conversion.
Trying to keep this post from getting too long: the key is that there is absolutely no substitute for a solid understanding of the theory behind database design. You simply cannot be anything more than a witless hack at databases without this understanding. You will churn out terrible database layouts almost every time (unless you have an unbelievably lucky streak) and your projects will suffer because of this.
Sorry if this sounds harsh, but it really, truly is worth spending the time to learn the theory and design before trying to apply your efforts to a real world project. Of course, if you're impatient you can play around with a server at the same time you learn the theory. But do not make the mistake of neglecting the theory in favor of quickly learning the syntax.
Brings back memories of a previous job I held. Our server room (about 40x65 feet) was a glass-enclosed room with a raised floor for cabling and ventilation. The AC unit was the size of four industrial refridgerators side by side. The UPS was a cabinet slightly larger than the AC unit and held dozens of batteries in series which could keep the equipment in the room running for 30 minutes -- more than enough time for the outside generator to kick in. Each battery was roughly what you would find in a large truck.
The room housed the servers for our local network and for the WAN which consisted of roughly two dozen buildings scattered around the county. We had a mix of HP/UX, Linux and NT servers -- and even one MPE/iX box (an HP3000 server). We also had our dial in, frame relay, outside Internet connection and terminal servers in the room. I believe there were 6 rackmount cabinets for most of the servers and the network equipment (the HP3000 and our voicemail systems were their own fridge-sized units outside the cabinets).
It was actually separated in to two parts, as well. The main room, which housed the actual servers, was about 40x50 feet. The second part was separated by a glass wall and was 40x15 feet. The smaller area had desks and a couple enclosed rooms where the support staff would usually work. Hardware work was done inside the main server room because of the air control.
The main things done right with the room were:
- AC Unit: this thing kept the room at a nice 54 degrees Fahrenheit no matter what was going on outside. The AC in the rest of the building would go out and everyone would start opening windows and turning on their desk fans, while I would retreat to the server room and put on my fleece.
- The raised floor: We never had a single cable on the floor to trip someone, and we could put a power outlet anywhere in the room we wanted. The floor was about a foot and a half off the real floor and covered the entire room. I loved that raised floor.
- Security: Sure, someone could break the glass walls (although the building's security system included glass break detectors in the server room), but the doors were very heavy and very thick. Access was controlled by individual keycodes which we had to change regularly. Out of the 50 plus people working in the same area of the building the server room was located, three of us had passcodes to the server room. So we always knew when someone was in there because one of us would have to escort them in and out of the room.
- Shelving: We had tons of shelving. We devoted one side of the room to just aisles of shelves, all clearly marked with their contents. The actual types of items were kept in alphabetized order. So, we had our boxes of cables near the first aisle, memory was near the middle and "Wyse" terminals near the end (a brand of basic vt102 dumb serial terminals).
- Deskspace: My desk actually was located in our server room, though I was usually on call in another building. But we also had an "island" in the middle of the room for general use. It was large enough to have four people simultaneously working on hardware with all their components spread out around them. We also had a couple workstations on the island that could be used to log in to the various servers and other equipment. These were convenient because they could remain logged in with privileged access to certain servers and we didn't have to worry about someone using them when we went to chat with mother nature since access to the room was stricly controlled.
The only complaint I ever had about the room was that when we would get shipments of 100 new workstations, they would cramp the room up a little until we got them all set up and shipped out to the various other buildings.
The suggestions I would make for things to consider when setting up a new server room:
- AC (obviously) and UPS (obviously)
- Raised floor (you can get by without one, but when you have one you never want to get rid of it)
- Entranceway security and if possible video monitoring
- Strict, enforceable access policy (there's no need for the the new graphics temp to be wandering around in the server room, but sometimes you'll want to be able to escort the VP through the room so he/she can see all the pretty blinking lights)
- 1.5 times the rackspace for your initial machine count at minimum, with twice the space initially needed reserved for cabinets
- Tons and tons of shelving, plastic ties, rubber bands, electrical tape and sticky labels. You never have enough of any of these things. Get plenty of bins of various sizes, too, to use on the shelves for things like screws, jumpers, adapters, etc.
- It's really helpful to have a common area for all the tools. We actually didn't do this at first and we'd lose a crimper or a screwdriver or something once or twice a week (more often than not we'd find them under the raised floor).
- If you find you're running a lot of cables in the to ceiling to distribute to the rest of the building, get some regular PVC plumbing pipes and a hacksaw to create basic conduits in to the ceiling and then above the ceiling to outside the walls of the server room. One of the easiest ways to feed cables through these is to get a string and tie it in to a loop where it will run one length inside the PVC pipe and another length outside. Create a few loopholes in the string and then whenever you want to feed a cable through it, hook the cable's connector in to a loop and then pull the string.
I definitely have to agree with this. I live and work in Fairfax as well. The lower rents and other fees, coupled with the stronger relative purchasing power for similar salaries has always made me wonder why places like SF were viewed as the only "reasonable" place for high tech companies.
I've just been suprised that the presence of some of the largest network providers in the world just down the road in Tysons/McLean hasn't made this area more of a hot spot for technology companies already. Sure, we've got AOL, Mae East (a complex of tier 1 providers) and a couple Oracle buildings among other big companies, but the DC Metro area's not usually associated with high tech.
And honestly, I wouldn't mind it staying that way seeing what has happened over in SF the past few years. I kind of like having money left each month after paying rent and utilities.
Bit more expensive than the price given for Telia in SE, but compared to some of the third-party resellers that have to lease through others like Covad and the phone company, it's a good price for the area. Service has been wonderful for the past 2 years (i.e. no more than 30 minutes of downtime every 4 or so months).
Unfortunately, I don't qualify for the faster services yet. But, the only thing that really would be useful in addition to what I have (for me, the 768 down is fast enough, and I don't host anything from home) would be a static IP. I would only need one, just enough to be able to SSH in to home from the office when I forget my laptop but need a file off of it.
For now I just have a script set up that "phones home" to my office machines every hour or so. It works, but it's not as convenient as knowing the IP by memory (for those extremely rare times I'm not at home or the office).
Please don't take this personally, but the analogy is not only incorrect, but absurd. Yes, it would be perfectly legal for Heinz to only do business with Hot-Dog Bob if they like his hot dog stand better than any others. Would Heinz be shooting themselves in the foot by not providing wider dissemination of their product? Of course.
But that doesn't change the fact that they are allowed to do so. Heinz cannot be forced to sell their ketchup to Hamburger Fred if they decide they don't want to. They don't need any reason other than not wanting to. Why do you think you see computer stores that advertise "Sony/Apple/etc. Authorized Dealer"? It's because those are the stores that the respective company chose they wanted to sell to. Conversely, I cannot just open up a little hole in the wall computer store and force Sony to sell to me.
The only analogy that could make sense for the purpose of your argument would be comparing software distribution to the utility monopolies. Dominion Virginia Power can, unlike Heinz, be forced to sell their electricity to Hamburger Fred's corporate office, presuming he lives in their service area, signs up for an account, has a credit history that passes the minimum requirements and adheres to all the rules of paying on time, not reselling the power without prior license/consent/approval/whatever. But, the difference here is that DVP can only be told to do so because they are Hamburger Fred's one and only option for connecting to the public power grid.
Ketchup, and software, are nothing like that. There is no "natural monopoly" on software. There may be some unnatural obstacles such as patents and illegally aggressive business practices by other companies, but just because ACME Corp. sells a word processor does not prevent JimBob Inc. from selling theirs as well.
Consider the following situation. XYZ Inc. sells graphics software for the Mac OS platform. They're a small company but make a great product that graphic designers and artists on Macs dig. But, they don't have the resources to target multiple platforms right now.
Well, sucks for people not using Macs that may want to use that program. Oh well, there's nothing stopping another company, or even an open source project, from making a similar product for other platforms, except time and money.
So, you say, "Well, I don't have the time or the money, but I really want that software." Well, XYZ Inc. may want you to have the software, too, but they don't have the time or money to do so.
Basically, your position boils down to that you aren't really interested enough in that software to either do it yourself, buy in to the necessary platform or make it financially viable for the company to add the resources to get it to you. You would rather legislate to them that they must cater to your whims of platform, regardless of how thin it will spread their resources.
In fact, in your second paragraph you even go so far as to state that XYZ Inc., if they don't have the resources to provide a Windows version of their software, should "[give] their code to other operating-systems so that they can produce a workable solution." Does that mean that if XYZ Inc. can't afford anything but a Mac version they should just hand over their code to Microsoft (for a Windows port), Palm (a Palm and Be port), IBM (AIX, z/OS, etc.), Sun, HP, SGI, RedHat (or any other Linux distributor -- or should it be Linus, the copyright holder, or FSF the license's creator) and the other dozens of companies and individuals that create or maintain operating systems?
Where do you draw the line with operating systems? What if the current owner of a PDP-11 says they want a port of the software, however infeasible? Is XYZ Inc. forced to either devote their own resources to it or hand the code over to AT&T? What about Mac OS 5? It's a deprecated operating system, but there may be someone out there that still uses it. XYZ Inc. makes a Mac version, but it will almost certainly not work on such an old version. Who are they then forced to hand the code to for the Mac OS 5 port? I'd be willing to bet my next several paychecks that Apple would laugh at the idea.
What about software that doesn't, and simply never will, run on other platforms? I may really want 12" tape reader control software for the embedded operating system in my cell phone, but it's not going to happen. No matter how much I really want to use my old tapes to backup the phone numbers, it is ridiculous to assert that ABC Inc. (fictional company; I don't actually own a 12" tape reader or control software for one) that made the software for the tape reader should be forced to port their software to my cell phone or hand over all their code so that someone else can do it. If they don't want to do so, then it should be their decision.
The real world doesn't work that way. And in a free market society, it should never have to, because we have the choice to either make it financially worth the company's while, find another company with a similar product who does cater to our needs or to try and do it ourselves. But we should not be able to dictate their platform to them through any means other than as consumers who may or may not purchase/use the software. It's a different matter when the platform choice is part of contract development between businesses, but then just about all the rules are different.
Practically no software company could survive if things worked the way you suggested, and we would all be the worse for it.
Because it isn't "X-Windows". It is either "X" or "X Window System." Release specific names follow the format of "X<version>R<release>," with the latest being X11R6.5.1, IIRC.
At least with Win2K Pro, I put the card in, installed the drivers off the CD that came with it, and viola. Tears the Philips Acoustic Edge to pieces, but mainly because this card *works*. With the Philips, I was getting terrible clicking and popping every time a sound played. Didn't matter what the source was. MP3s and CDs that sounded beautiful under Linux were unlistenable with the AE.
But, the Audigy (I got the Audigy Platinum with the 5.25" bay thingy) is great. I've had it in there for about a week without a single problem. And I love the drive bay add-on. Not only does it have knobs and connectors (lots of them), but they actually do stuff. Good stuff.
I'm running RH7.0 on the slimtop LX900 which has an SiS chipset. This may not be relevant because of the different video chipsets, btu I thought I would mention it anyway...
To get X working, I had to use the framebuffer for the virtual consoles. I made sure the kernel had FB support for the SiS chipset (had to upgrade to a 2.4.x kernel for the driver), and then added the line "vga=0x305" above the image entries in my/etc/lilo.conf file. This puts the console into 1024x768x16 at boot, and tehn I used the FBDev driver for X. OpenGL even works reasonably well on the machine (not enough for games, but well enough for some of the GL xscreensaver hacks to run smoothly).
Like I said, since the machines use different chipsets, it may not be relevant, but that's how I got my slimtop running X. Overall, the machine runs beautifully under Linux.
Not that I disagree with you personally, I have to take issue with two of your comments.
First, you make mention of how "everyone seems to think that managers are these 'super-people'..." (emphasis not mine). While I definitely cannot speak for everyone, as you seem to be able to, I know I can speak for myself and many of the people I work with and have worked with in that past, when I say that this is hardly true. I know that managers are just 'regular people', and far more often than not, they are the ones who don't have the knowledge to actually do the work, but do have the belief that they can tell others how the work is to be done.
Only once in my entire career have I known a manager who truly understood the work/projects he was managing. Unfortunely, he was not one of my managers, but a friend's. He was an excellent programmer who had filled a managerial position on the project he was working on after the previous manager was promoted to higher levels. After a year he couldn't take dealing with management above him anymore and left for a startup company. Instead of being replaced by one of the other programmers who were equally skilled, a non-programmer was sent over to manage the project. Within two months, all but one member of the staff on the project had left the company in disgust. My friend has tried to weather the new manager as best as he can, but is now pursuing offers from other companies. He will be the last of the pre-new-manager staff to leave, causing a 100% turnover in under six months.
What triggered the ridiculous turnover was what I have begun to realize is typical of many managers who have no true understanding of what they're really managing. Promises were constantly made to other departments and higher level management with no consulting of his staff, ridiculous deadlines were constantly imposed, staff members were constantly being shuffled around in the project to meet each new far-fetched promise being made, and despite their efforts, staff members were never allowed to participate in any of the discussions that led to new promises and deadlines.
The new manager didn't care at all about how much damage he was doing to morale, how disillusioned his employees were becoming with all the changes in direction and having no input into anything, nor did he listen when his employees were trying to tell him things were not working out very well. His sole concern was looking good to other managers and the higher levels by committing to anything they asked him for.
Along the same vein, I also have to take issue with another point you make about managers: "without a doubt, everything these people do is with the purist of intentions". With the experiences my friends and I have had, this made me laugh out loud.
I have yet to meet a single manager myself whose intentions were not riddled with self-promotion, ego, blind ambition, and a total lack of respect for the fact that he/she is screwed without the blood, sweat and tears of his/her employees -- or a combination thereof.
There are most certainly good managers out there, and even some outstanding ones. You may well be one of those managers (largely because you don't sound like any manager I've ever known personally), but my experiences have always been with managers whose total lack of knowledge in their field has never hindered their outlandish promises, their expectations founded in crack-induced hallucinations, and their purely selfish and political motives aimed at bettering their own personal image at any cost to their employees.
If you can honestly say that you have never made a promise for a deadline or a project or anything else to another manager or higher up without first consulting with your employees, considering at full weight their input, and have never let creep in any ulterior motive (i.e. "if I promise them this feature and work my guys hard enough so they get it done, I'll look great and may get that promotion"), then I would love to know if you're hiring. If so, and if I'm competent and interested in the field in which you'll be hiring, I will file an application and send my resume very shortly.
My basic point is that you can't assume this guy's managers are as well-intentioned as you seem to be (and I truly would commend you on an excellent job if you've avoided the pitfalls I'm so apt to gripe about). While my optimistic side would have me believe that maybe I've just been unlucky with managers and that one day maybe I'll meet a manager that is competent and does truly have only good intentions for the employees and the company, that hope is quickly drowned out by two things. First, I'm not an optimist. Second, I see the same things happening to many of my friends and fellow programmers on an all too frequent basis.
That's quite untrue, actually. Sounds like someone with stock in a particular distro company may have told you that.;-)
Under all but rare or weird circumstances upgrading to a newer kernel will only break a program if it relies on a special module or patched code in the kernel that the distro makeer has pre-applied to the kernel and that is not standard with stock kernel downloads. These kinds of programs are few and far between.
Recompiling a kernel is not a sacred initiation rite for the elite. It's actually very easy as long as you understand the hardware in your system (you'll need to know specific model numbers and such for just about everything in your system that you want to get working properly; you can consult the files under/proc to get just about every bit of information you need), and follow all the proper instructions.
You can either look below for very brief instructions, or download and untar the kernel and read the README file in the newly created linux/ directory where you untarred.
The very abbreviated instructions are: download kernel, ungzip and untar the kernel in/usr/src (remove the existing/usr/src/linux symlink first), rename new linux/ directory to something else, then recreate/usr/src/linux symlink to that directory. Then, cd into/usr/src/linux and do "make " plus either config, menuconfig or xconfig. For beginners, menuconfig or xconfig are best (you'll need to be running X for the latter to work). Configure the kernel as you need/want, then save & exit. Type "make dep", then "make bzImage", then (if you selected any options to be compiled as modules) "make modules" and "make modules_install".
Copy/usr/src/linux/arch/"your platform"/boot/bzImage to/boot/vmlinuz-"something unique". Replace "your platform" with i386 for Intel, "alpha" for Alpha, and so on. Then edit/etc/lilo.conf. For details on lilo.conf, do "man lilo.conf". If you're using LILO and have edited lilo.conf, make sure to rerun "/sbin/lilo" before rebooting your system.
Most configuration options for the kernel have decent little bits of info attached to them saying what they're for (hit "?" with the option selected to see the help text).
Hope that helps. If not, read the README a couple times. If you're ever unsure about a kernel option, look for documentation on it under the linux/Documentation directory. There's detailed info in there for most options in the kernel.
i've been using the logitech wireless keyboard and cordless mouseman wheel (the funny shaped one that logitech seems to only make for us righties, unfort. for some).
in the year i've had them i've only had the replace the batteries for each once (two AA for the kb and two AAA for the mouse) and have been very pleased with their performance.
_however_... several months ago one of the other people at the office got the same setup and was using it about 6 feet from mine. the interference would actually get so bad sometimes that i couldn't type and when he'd hold down the backspace key to remove a chunk of text, it'd actually delete stuff on my active terminal/program as well. we could never see what each other typed, though. it only seemed to be the backspace, delete and space keys that would show up on each other's machines.
once we moved our receivers as far away as possible (about 12 feet), the interference dropped significantly, but was still an annoyance every once in a while. he eventually gave up and went back to a wired keyboard. the mice never seemed to mind each other.
the main thing i appreciate about these is that they're radio, not infrared, so i have the receivers taped to the bottom of my desk (off to the side so my knees don't hit them). there's no line-of-sight problems, and they work fine up to about 8 feet away (spec says 6 feet).
I'm not sure how far outside of the East Coast U.S. SunTrust reaches, but I haven't ever regretted opening accounts with them.
They've always provided a clean and fast web interface to my accounts, including free online bill pay, and downloading of past statements. I also recently started using them as my broker, and have to say I'm also quite happy with their web interfaces for doing this as well.
I can access my deposit accounts, money market, credit card, and investment portfolio (including executing trades) via the web, and haven't ever had a problem doing this under Linux. My investment advisor from the regional branch (a couple blocks down the road from my office) is even quite familiar with Linux. They do use a little Javascript on some of the sites, but they have done a very good job at making sure it works under all the various platforms.
Anywho, just thought I'd toss that in for anyone in the East Cost U.S. looking for a reputable bank that has full Linux support for all the online banking/investment functions.
I've been very happy with my PalmVx with the OmniSky wireless modem. I think the OmniSky comes out of the public beta very soon (as in a month or so).
While it's not terribly cheap ($300 for the modem), the service will be a flat monthly rate, regardless of the amount of traffic, and works over AT&T's digital network which covers pretty much the whole country.
It comes standard with e-mail (up to 6 POP accounts, with automatic polling & notification (via a red LED on the front of the modem)), web browser (including graphics if you want to wait for them to download), stock (E*Trade), weather (Weather Channel), traffic (Etak), directions (via MapQuest) and any other web-clipping app you sync to your Palm.
The modem itself is only 19.2Kbps, but that's more than enough to download my e-mail when I'm stuck in traffic on the Beltway. You would be very tight for space if you try it with a regular 2MB Palm V, since the OmniSky software uses 1MB on the Palm.
Overall, I've been really happy with it, if for no other reason than it looks infinitely better than the Palm VII. The modem fits right in with the sleek design of the Palm V series.
OmniSky's website is, surprisingly enough, http://www.omnisky.com/
I co-own a company that was recently slashdotted. We had the site running on a PII-450 with 128MB of memory, on a 10MB Ethernet connection (direct to the backbone; we also own/run an ISP). For a vast majority of sites out there, this machine would never have had any trouble taking whatever Slashdot could throw at it (so this configuration could be great for your needs).
However, our site is very heavy on the dynamic content (and uses a lot of SSL for the ordering system).
The machine could handle about 20 minutes of the/. effect at a time before the CPU time went sky high. Luckily, we were able to bring the machine down, put in a second processor and double the memory (we also updated mod_perl); and get the machine back up in a couple hours with the new configuration.
The machine has been running like an absolute champ for the past few days. It's been able to handle requests numbering in the millions (page hits are in the hundreds of thousands, but our site uses a fair amount of graphics also) and has transferred several GBs of data just this weekend. If you do anything securely (SSL), keep in mind that anything on that secure page will take up about 7 to 8 times the CPU time as a non-secure item. And never, never, never run a site using Perl for dynamic content without installing mod_perl for Apache. The difference between a machine with it and one without it is tremendous (especially in memory usage).
One thing you can do for big gains in speed is disable hostname lookups (this makes a huge difference when being slashdotted). Also, turn the log level down on Apache. Because we have space to spare on this particular machine, we have the logging set at a moderate level. After two days since the mention on Slashdot, the logs are a few hundred MB. Not a problem if you have the disk space, but if you don't it will be a major problem.
Anyway, the configuration now is: dual PII-450, 256MB of ECC PC100 SDRAM, 10MB Ethernet on kernel 2.2.12 running Apache 1.3.9 and Perl 5.005 (along with the latest OpenSSL, SSLeay and mod_perl). It's having no problem keeping up with the load at this point, and the traffic is still pretty heavy.
Slashdot Mirror
You are definitely correct that proper design is the way to go. I would never argue against that. However, my original point is that there are certain problems that are better solved by stored procedures. If you can avoid sending out a several dozen MB each time a query is run by spending an extra second on the database server to do some additional processing, and if it supports your business goals, I would say that is a situation that could benefit from stored procedures.
And quickly, as for your last comment, I also agree. Overuse of any feature is not a good thing -- even if it's a feature you like. You might be surprised since it may seem that I am advocating the use of stored procedures more than you may like, but I have not used a single one in the past year in any of my applications (which support tens of thousands of users each day and are mission critical for our business). Why? They weren't appropriate solutions to any of the problems.
What I am arguing against is the notion from some people that stored procedures are *never* needed because they can be "emulated" in the client layer which is untrue.
That would alleviate some of the problems, but it does not solve all of them, and it even introduces new ones.
What it does solve is the deployment problem of updating hundreds of client applications. You would only need to update this intermediary server that sits in between the clients and the database.
What it does not solve is the fact that you will still have to transfer all data from the database server to another machine before you do any work on the data. And you still need to allocate effectively twice as much memory as you would if you just kept the data on the database server and used stored procedures when appropriate.
However, here are just a few of the new problems your solution introduces:
Your clients no longer just connect to a database server. They're connecting to a piece of middleware which will broker all connections. This can be an advantage for some types of applications, but it is more difficult to implement and could very well increase your code base significantly. Not to mention, if your programmers don't have the experience implementing solid middleware solutions, your setup could be very inefficient.
What about all the database queries that don't need the stored procedures? Your solution gives two options. a) Each client maintains one connection to the database server directly and one connection to the middleware server. b) All requests go through the middleware. The first option introduces new complexities in to the code, and puts more of the responsibility for deciding when to query the database and when to use a stored procedure on the software developers, not the database designers. In general, that is not a good thing, unless your programmers are also DBAs (or equivalent/better knowledge).
The second option is terribly inefficient. You now have to transfer all the data from the database server to the middleware, then from the middleware to the client. At least twice as much traffic as you should be generating for cases where the middleware didn't actually need to do anything to the data itself.
I'm not saying that middleware is inherently bad. It is a very appropriate (if not exclusive) solution for many problems. But, to say that you don't need stored procedures because "we can stick another server in between the clients and the database" is a very poor solution.
Your statement shows you don't understand the real benefits of stored procedures. Say you have a very common task that, unfortunately, needs to work on a large set of data, but consistently results in only a few rows of data when it has finished going through all the data. Now, which of the following two options is better:
1. The original large set of data (say, 10MB) is transferred over the network to the front end machine which then runs through it's motions and trims that dataset down to the final 8KB of data actually needed. Aside from the IO, both machines need to reserve 10MB of memory to store the data set, plus additional memory for intermediary data structures while the code works.
2. The original 10MB of data stays on the database server, never being sent over the network to the front end machine. The stored procedure works on the original data culled from the database, does it's magic, and then transfers the final 8KB worth of data over the network to the front end machine. While the database server still needs to allocate 10MB for the dataset plus memory for intermediary data structures, the front end machines only has to allocate 8KB of memory for the final results -- plus, 10MB of data never needed to be transferred over the network.
If you answered #2, you've just given one example of why stored procedures can be a far better way to handle certain problems. They're no panacea, but "emulating" stored procedures in your front end application is a horrible way to justify not providing stored procedures in a database server.
If that example wasn't enough for you, consider the following.
You have an enterprise department consisting of a few hundred employees all running a GUI application which connects to a database to allow access to financial/customer/product/whatever data to all the employees. Various inquires in to the data need to compute values, collate data, or perform other complex operations on tens of thousands of ledger entries/customer accounts/products/whatevers.
Now, choose one of these two options:
1. You embed all, and I mean all (since you don't have stored procedures), logic relating to these inquiries in to the GUI application. You then update each workstation with the new version of the client to support the changes. This involves rolling out the new version to hundreds of machines, causing worker downtime for each machine (or a few very late nights and expensive overtime for your IT staff). Then you find out a few days later that your QA staff didn't catch a very problematic bug that affects half the staff. It turns out the bug was very easy to fix, but you now have to redeploy the updated application to the hundreds of machines -- again.
2. Your GUI application does not contain any of the logic relating to munging/collating/etc. the data in question. These are contained as stored procedures inside the database server. Your client application, installed on hundreds of machines, simply call this procedure on the database. You update the stored procedure and instantly all clients are now using the new version. A couple days later, you find out QA didn't find a problematic bug. Turns out, it was easy to fix, and in minutes all of the hundreds of machines now use the fixed version of the procedure.
As my last example, how exactly do you propose to be able to create effective triggers without some form of a stored procedure? Triggers are a wonderful feature (also lacking in MySQL) that go hand in hand with stored procedures. But, I've already been long winded enough in this post, so I'll wrap up.
Are you starting to get the picture? If stored procedures weren't so useful, nobody would want them. The real problem is that people who don't understand databases or database application design *think* that stored procedures can always be effectively "emulated" in the client layer, and so they *think* that stored procedures aren't useful.
You're correct, the submitter was an idiot. Xinerama has absolutely nothing to do with movies and everything to do with connecting multiple monitors to a single box.
:0.0, :0.1, etc.) and you cannot move windows between them. With Xinerama, you can make them act as a single display, allowing you to run only one instance of your window manager and drag windows between them.
;)
Xinerama is not necessary for multi-head setups. However, without it each monitor is a separate screen (i.e.
But, there is a downside. Hardware accelerated OpenGL for most video cards does not cooperate with Xinerama. I've been sort of waiting ever since XFree86 4.0 came out for nVidia to find a way around this in their drivers so that I can get away from software OpenGL rendering. I'm not holding my breath, though, as I imagine that splitting a single OpenGL scene at an arbitrary point across two completely separate devices is a tricky thing to handle very well.
The OpenGL problem aside, having several LCD screens all lined up next to each other is a Nice Thing. Just tell your boss you're more productive with such a setup -- I am honestly more productive being able to spread my work out over a wall of screens. I just run out of PCI slots real fast.
The two boxes sitting underneath the networking equipment in our network/server closet here at work. Sure, they're more expensive cube cases, but one actually has twelve drives in it. Linux and software RAID turns them in a great half terabyte (non-mission-critical) fileserver for the office.
Back in the days that I worked at a small ISP (there were five of us that ran the place, including all the dialup, colo and virtual hosting) I would actually keep a tail running on a separate screen for our radius logs. It provided me with early warning for when I would have to hide and get that chat icon above my character's head in Quake so that I could answer a call from a user who forgot their username or password.
Do *not* learn the actual query language first. Learn database theory and design before anything else. Don't even consider doing anything with a database until you know the six forms of normalization (at a bare minimum you need to know the first three; the second three are "gravy" for many applications and not even appropriate all the time). This includes knowing the requirements to reach each level of normalization within a database.
I have seen so many database layouts for various applications that have practically brought me to tears through their sheer stupidity. These were layouts designed purportedly by people who "knew SQL." There is a tremendous difference between "knowing SQL" and "knowing proper database design and implementation." Unfortunately, many people who claim to be database programmers do not realize there is a difference and assume that since they know the syntax of SQL, they know how to design a database.
I would recommend that you begin with "Database Systems" by Connolly and Begg. Read it cover to cover, then read it again. When you're done reading it the second time, skip through to the end of each section and do all the exercises without rereading any of the text. Once you can answer a majority of the questions correctly, then begin to consider designing database layouts. Before you look the book up on fatbrain or amazon, be warned that it is not light reading. It's 1,200+ pages, but is well worth it.
The ISBN is: 0201708574.
When you actually understand how databases work and how to effectively use them, you will thank yourself tremendously for taking the time up front. If you dive right in to learning the syntax of the query language without understanding the basics of design and implementation, you will make one stupid mistake after another with no end in sight. Then, someone more knowledgeable than yourself will come along and will have to start everything over from scratch to fix your screwups.
Doing it right the first time is especially important when designing databases for large systems. If you screw something up and don't learn from your mistake until you have millions of records in tables that are being quickly updated 24/7, fixing that mistake is going to be a nightmare and could very well cost your company a tremendous amount of money through downtime and resources spent on the fix and conversion.
Trying to keep this post from getting too long: the key is that there is absolutely no substitute for a solid understanding of the theory behind database design. You simply cannot be anything more than a witless hack at databases without this understanding. You will churn out terrible database layouts almost every time (unless you have an unbelievably lucky streak) and your projects will suffer because of this.
Sorry if this sounds harsh, but it really, truly is worth spending the time to learn the theory and design before trying to apply your efforts to a real world project. Of course, if you're impatient you can play around with a server at the same time you learn the theory. But do not make the mistake of neglecting the theory in favor of quickly learning the syntax.
Brings back memories of a previous job I held. Our server room (about 40x65 feet) was a glass-enclosed room with a raised floor for cabling and ventilation. The AC unit was the size of four industrial refridgerators side by side. The UPS was a cabinet slightly larger than the AC unit and held dozens of batteries in series which could keep the equipment in the room running for 30 minutes -- more than enough time for the outside generator to kick in. Each battery was roughly what you would find in a large truck.
The room housed the servers for our local network and for the WAN which consisted of roughly two dozen buildings scattered around the county. We had a mix of HP/UX, Linux and NT servers -- and even one MPE/iX box (an HP3000 server). We also had our dial in, frame relay, outside Internet connection and terminal servers in the room. I believe there were 6 rackmount cabinets for most of the servers and the network equipment (the HP3000 and our voicemail systems were their own fridge-sized units outside the cabinets).
It was actually separated in to two parts, as well. The main room, which housed the actual servers, was about 40x50 feet. The second part was separated by a glass wall and was 40x15 feet. The smaller area had desks and a couple enclosed rooms where the support staff would usually work. Hardware work was done inside the main server room because of the air control.
The main things done right with the room were:
- AC Unit: this thing kept the room at a nice 54 degrees Fahrenheit no matter what was going on outside. The AC in the rest of the building would go out and everyone would start opening windows and turning on their desk fans, while I would retreat to the server room and put on my fleece.
- The raised floor: We never had a single cable on the floor to trip someone, and we could put a power outlet anywhere in the room we wanted. The floor was about a foot and a half off the real floor and covered the entire room. I loved that raised floor.
- Security: Sure, someone could break the glass walls (although the building's security system included glass break detectors in the server room), but the doors were very heavy and very thick. Access was controlled by individual keycodes which we had to change regularly. Out of the 50 plus people working in the same area of the building the server room was located, three of us had passcodes to the server room. So we always knew when someone was in there because one of us would have to escort them in and out of the room.
- Shelving: We had tons of shelving. We devoted one side of the room to just aisles of shelves, all clearly marked with their contents. The actual types of items were kept in alphabetized order. So, we had our boxes of cables near the first aisle, memory was near the middle and "Wyse" terminals near the end (a brand of basic vt102 dumb serial terminals).
- Deskspace: My desk actually was located in our server room, though I was usually on call in another building. But we also had an "island" in the middle of the room for general use. It was large enough to have four people simultaneously working on hardware with all their components spread out around them. We also had a couple workstations on the island that could be used to log in to the various servers and other equipment. These were convenient because they could remain logged in with privileged access to certain servers and we didn't have to worry about someone using them when we went to chat with mother nature since access to the room was stricly controlled.
The only complaint I ever had about the room was that when we would get shipments of 100 new workstations, they would cramp the room up a little until we got them all set up and shipped out to the various other buildings.
The suggestions I would make for things to consider when setting up a new server room:
- AC (obviously) and UPS (obviously)
- Raised floor (you can get by without one, but when you have one you never want to get rid of it)
- Entranceway security and if possible video monitoring
- Strict, enforceable access policy (there's no need for the the new graphics temp to be wandering around in the server room, but sometimes you'll want to be able to escort the VP through the room so he/she can see all the pretty blinking lights)
- 1.5 times the rackspace for your initial machine count at minimum, with twice the space initially needed reserved for cabinets
- Tons and tons of shelving, plastic ties, rubber bands, electrical tape and sticky labels. You never have enough of any of these things. Get plenty of bins of various sizes, too, to use on the shelves for things like screws, jumpers, adapters, etc.
- It's really helpful to have a common area for all the tools. We actually didn't do this at first and we'd lose a crimper or a screwdriver or something once or twice a week (more often than not we'd find them under the raised floor).
- If you find you're running a lot of cables in the to ceiling to distribute to the rest of the building, get some regular PVC plumbing pipes and a hacksaw to create basic conduits in to the ceiling and then above the ceiling to outside the walls of the server room. One of the easiest ways to feed cables through these is to get a string and tie it in to a loop where it will run one length inside the PVC pipe and another length outside. Create a few loopholes in the string and then whenever you want to feed a cable through it, hook the cable's connector in to a loop and then pull the string.
I definitely have to agree with this. I live and work in Fairfax as well. The lower rents and other fees, coupled with the stronger relative purchasing power for similar salaries has always made me wonder why places like SF were viewed as the only "reasonable" place for high tech companies.
I've just been suprised that the presence of some of the largest network providers in the world just down the road in Tysons/McLean hasn't made this area more of a hot spot for technology companies already. Sure, we've got AOL, Mae East (a complex of tier 1 providers) and a couple Oracle buildings among other big companies, but the DC Metro area's not usually associated with high tech.
And honestly, I wouldn't mind it staying that way seeing what has happened over in SF the past few years. I kind of like having money left each month after paying rent and utilities.
$39.95/mo. for 768/128Kbps.
Bit more expensive than the price given for Telia in SE, but compared to some of the third-party resellers that have to lease through others like Covad and the phone company, it's a good price for the area. Service has been wonderful for the past 2 years (i.e. no more than 30 minutes of downtime every 4 or so months).
Unfortunately, I don't qualify for the faster services yet. But, the only thing that really would be useful in addition to what I have (for me, the 768 down is fast enough, and I don't host anything from home) would be a static IP. I would only need one, just enough to be able to SSH in to home from the office when I forget my laptop but need a file off of it.
For now I just have a script set up that "phones home" to my office machines every hour or so. It works, but it's not as convenient as knowing the IP by memory (for those extremely rare times I'm not at home or the office).
Please don't take this personally, but the analogy is not only incorrect, but absurd. Yes, it would be perfectly legal for Heinz to only do business with Hot-Dog Bob if they like his hot dog stand better than any others. Would Heinz be shooting themselves in the foot by not providing wider dissemination of their product? Of course.
But that doesn't change the fact that they are allowed to do so. Heinz cannot be forced to sell their ketchup to Hamburger Fred if they decide they don't want to. They don't need any reason other than not wanting to. Why do you think you see computer stores that advertise "Sony/Apple/etc. Authorized Dealer"? It's because those are the stores that the respective company chose they wanted to sell to. Conversely, I cannot just open up a little hole in the wall computer store and force Sony to sell to me.
The only analogy that could make sense for the purpose of your argument would be comparing software distribution to the utility monopolies. Dominion Virginia Power can, unlike Heinz, be forced to sell their electricity to Hamburger Fred's corporate office, presuming he lives in their service area, signs up for an account, has a credit history that passes the minimum requirements and adheres to all the rules of paying on time, not reselling the power without prior license/consent/approval/whatever. But, the difference here is that DVP can only be told to do so because they are Hamburger Fred's one and only option for connecting to the public power grid.
Ketchup, and software, are nothing like that. There is no "natural monopoly" on software. There may be some unnatural obstacles such as patents and illegally aggressive business practices by other companies, but just because ACME Corp. sells a word processor does not prevent JimBob Inc. from selling theirs as well.
Consider the following situation. XYZ Inc. sells graphics software for the Mac OS platform. They're a small company but make a great product that graphic designers and artists on Macs dig. But, they don't have the resources to target multiple platforms right now.
Well, sucks for people not using Macs that may want to use that program. Oh well, there's nothing stopping another company, or even an open source project, from making a similar product for other platforms, except time and money.
So, you say, "Well, I don't have the time or the money, but I really want that software." Well, XYZ Inc. may want you to have the software, too, but they don't have the time or money to do so.
Basically, your position boils down to that you aren't really interested enough in that software to either do it yourself, buy in to the necessary platform or make it financially viable for the company to add the resources to get it to you. You would rather legislate to them that they must cater to your whims of platform, regardless of how thin it will spread their resources.
In fact, in your second paragraph you even go so far as to state that XYZ Inc., if they don't have the resources to provide a Windows version of their software, should "[give] their code to other operating-systems so that they can produce a workable solution." Does that mean that if XYZ Inc. can't afford anything but a Mac version they should just hand over their code to Microsoft (for a Windows port), Palm (a Palm and Be port), IBM (AIX, z/OS, etc.), Sun, HP, SGI, RedHat (or any other Linux distributor -- or should it be Linus, the copyright holder, or FSF the license's creator) and the other dozens of companies and individuals that create or maintain operating systems?
Where do you draw the line with operating systems? What if the current owner of a PDP-11 says they want a port of the software, however infeasible? Is XYZ Inc. forced to either devote their own resources to it or hand the code over to AT&T? What about Mac OS 5? It's a deprecated operating system, but there may be someone out there that still uses it. XYZ Inc. makes a Mac version, but it will almost certainly not work on such an old version. Who are they then forced to hand the code to for the Mac OS 5 port? I'd be willing to bet my next several paychecks that Apple would laugh at the idea.
What about software that doesn't, and simply never will, run on other platforms? I may really want 12" tape reader control software for the embedded operating system in my cell phone, but it's not going to happen. No matter how much I really want to use my old tapes to backup the phone numbers, it is ridiculous to assert that ABC Inc. (fictional company; I don't actually own a 12" tape reader or control software for one) that made the software for the tape reader should be forced to port their software to my cell phone or hand over all their code so that someone else can do it. If they don't want to do so, then it should be their decision.
The real world doesn't work that way. And in a free market society, it should never have to, because we have the choice to either make it financially worth the company's while, find another company with a similar product who does cater to our needs or to try and do it ourselves. But we should not be able to dictate their platform to them through any means other than as consumers who may or may not purchase/use the software. It's a different matter when the platform choice is part of contract development between businesses, but then just about all the rules are different.
Practically no software company could survive if things worked the way you suggested, and we would all be the worse for it.
Because it isn't "X-Windows". It is either "X" or "X Window System." Release specific names follow the format of "X<version>R<release>," with the latest being X11R6.5.1, IIRC.
See man 7 X for more details.
At least with Win2K Pro, I put the card in, installed the drivers off the CD that came with it, and viola. Tears the Philips Acoustic Edge to pieces, but mainly because this card *works*. With the Philips, I was getting terrible clicking and popping every time a sound played. Didn't matter what the source was. MP3s and CDs that sounded beautiful under Linux were unlistenable with the AE.
But, the Audigy (I got the Audigy Platinum with the 5.25" bay thingy) is great. I've had it in there for about a week without a single problem. And I love the drive bay add-on. Not only does it have knobs and connectors (lots of them), but they actually do stuff. Good stuff.
Maybe you should try reading the fine manual. You can *very* easily disable this behavior.
First:
Preferences --> Advanced
Then:
Preferences --> Windows & Desktop
and uncheck "Use Nautilus to draw the desktop"
Now, that wasn't so hard, was it? Don't knock a great piece of software (even though I rarely use filemanagers) just because you didn't read the docs.
I'm running RH7.0 on the slimtop LX900 which has an SiS chipset. This may not be relevant because of the different video chipsets, btu I thought I would mention it anyway...
/etc/lilo.conf file. This puts the console into 1024x768x16 at boot, and tehn I used the FBDev driver for X. OpenGL even works reasonably well on the machine (not enough for games, but well enough for some of the GL xscreensaver hacks to run smoothly).
To get X working, I had to use the framebuffer for the virtual consoles. I made sure the kernel had FB support for the SiS chipset (had to upgrade to a 2.4.x kernel for the driver), and then added the line "vga=0x305" above the image entries in my
Like I said, since the machines use different chipsets, it may not be relevant, but that's how I got my slimtop running X. Overall, the machine runs beautifully under Linux.
Not that I disagree with you personally, I have to take issue with two of your comments.
First, you make mention of how "everyone seems to think that managers are these 'super-people'..." (emphasis not mine). While I definitely cannot speak for everyone, as you seem to be able to, I know I can speak for myself and many of the people I work with and have worked with in that past, when I say that this is hardly true. I know that managers are just 'regular people', and far more often than not, they are the ones who don't have the knowledge to actually do the work, but do have the belief that they can tell others how the work is to be done.
Only once in my entire career have I known a manager who truly understood the work/projects he was managing. Unfortunely, he was not one of my managers, but a friend's. He was an excellent programmer who had filled a managerial position on the project he was working on after the previous manager was promoted to higher levels. After a year he couldn't take dealing with management above him anymore and left for a startup company. Instead of being replaced by one of the other programmers who were equally skilled, a non-programmer was sent over to manage the project. Within two months, all but one member of the staff on the project had left the company in disgust. My friend has tried to weather the new manager as best as he can, but is now pursuing offers from other companies. He will be the last of the pre-new-manager staff to leave, causing a 100% turnover in under six months.
What triggered the ridiculous turnover was what I have begun to realize is typical of many managers who have no true understanding of what they're really managing. Promises were constantly made to other departments and higher level management with no consulting of his staff, ridiculous deadlines were constantly imposed, staff members were constantly being shuffled around in the project to meet each new far-fetched promise being made, and despite their efforts, staff members were never allowed to participate in any of the discussions that led to new promises and deadlines.
The new manager didn't care at all about how much damage he was doing to morale, how disillusioned his employees were becoming with all the changes in direction and having no input into anything, nor did he listen when his employees were trying to tell him things were not working out very well. His sole concern was looking good to other managers and the higher levels by committing to anything they asked him for.
Along the same vein, I also have to take issue with another point you make about managers: "without a doubt, everything these people do is with the purist of intentions". With the experiences my friends and I have had, this made me laugh out loud.
I have yet to meet a single manager myself whose intentions were not riddled with self-promotion, ego, blind ambition, and a total lack of respect for the fact that he/she is screwed without the blood, sweat and tears of his/her employees -- or a combination thereof.
There are most certainly good managers out there, and even some outstanding ones. You may well be one of those managers (largely because you don't sound like any manager I've ever known personally), but my experiences have always been with managers whose total lack of knowledge in their field has never hindered their outlandish promises, their expectations founded in crack-induced hallucinations, and their purely selfish and political motives aimed at bettering their own personal image at any cost to their employees.
If you can honestly say that you have never made a promise for a deadline or a project or anything else to another manager or higher up without first consulting with your employees, considering at full weight their input, and have never let creep in any ulterior motive (i.e. "if I promise them this feature and work my guys hard enough so they get it done, I'll look great and may get that promotion"), then I would love to know if you're hiring. If so, and if I'm competent and interested in the field in which you'll be hiring, I will file an application and send my resume very shortly.
My basic point is that you can't assume this guy's managers are as well-intentioned as you seem to be (and I truly would commend you on an excellent job if you've avoided the pitfalls I'm so apt to gripe about). While my optimistic side would have me believe that maybe I've just been unlucky with managers and that one day maybe I'll meet a manager that is competent and does truly have only good intentions for the employees and the company, that hope is quickly drowned out by two things. First, I'm not an optimist. Second, I see the same things happening to many of my friends and fellow programmers on an all too frequent basis.
That's quite untrue, actually. Sounds like someone with stock in a particular distro company may have told you that. ;-)
/proc to get just about every bit of information you need), and follow all the proper instructions.
/usr/src (remove the existing /usr/src/linux symlink first), rename new linux/ directory to something else, then recreate /usr/src/linux symlink to that directory. Then, cd into /usr/src/linux and do "make " plus either config, menuconfig or xconfig. For beginners, menuconfig or xconfig are best (you'll need to be running X for the latter to work). Configure the kernel as you need/want, then save & exit. Type "make dep", then "make bzImage", then (if you selected any options to be compiled as modules) "make modules" and "make modules_install".
/usr/src/linux/arch/"your platform"/boot/bzImage to /boot/vmlinuz-"something unique". Replace "your platform" with i386 for Intel, "alpha" for Alpha, and so on. Then edit /etc/lilo.conf. For details on lilo.conf, do "man lilo.conf". If you're using LILO and have edited lilo.conf, make sure to rerun "/sbin/lilo" before rebooting your system.
Under all but rare or weird circumstances upgrading to a newer kernel will only break a program if it relies on a special module or patched code in the kernel that the distro makeer has pre-applied to the kernel and that is not standard with stock kernel downloads. These kinds of programs are few and far between.
Recompiling a kernel is not a sacred initiation rite for the elite. It's actually very easy as long as you understand the hardware in your system (you'll need to know specific model numbers and such for just about everything in your system that you want to get working properly; you can consult the files under
You can either look below for very brief instructions, or download and untar the kernel and read the README file in the newly created linux/ directory where you untarred.
The very abbreviated instructions are: download kernel, ungzip and untar the kernel in
Copy
Most configuration options for the kernel have decent little bits of info attached to them saying what they're for (hit "?" with the option selected to see the help text).
Hope that helps. If not, read the README a couple times. If you're ever unsure about a kernel option, look for documentation on it under the linux/Documentation directory. There's detailed info in there for most options in the kernel.
i've been using the logitech wireless keyboard and cordless mouseman wheel (the funny shaped one that logitech seems to only make for us righties, unfort. for some).
in the year i've had them i've only had the replace the batteries for each once (two AA for the kb and two AAA for the mouse) and have been very pleased with their performance.
_however_... several months ago one of the other people at the office got the same setup and was using it about 6 feet from mine. the interference would actually get so bad sometimes that i couldn't type and when he'd hold down the backspace key to remove a chunk of text, it'd actually delete stuff on my active terminal/program as well. we could never see what each other typed, though. it only seemed to be the backspace, delete and space keys that would show up on each other's machines.
once we moved our receivers as far away as possible (about 12 feet), the interference dropped significantly, but was still an annoyance every once in a while. he eventually gave up and went back to a wired keyboard. the mice never seemed to mind each other.
the main thing i appreciate about these is that they're radio, not infrared, so i have the receivers taped to the bottom of my desk (off to the side so my knees don't hit them). there's no line-of-sight problems, and they work fine up to about 8 feet away (spec says 6 feet).
http://www.suntrust.com/
I'm not sure how far outside of the East Coast U.S. SunTrust reaches, but I haven't ever regretted opening accounts with them.
They've always provided a clean and fast web interface to my accounts, including free online bill pay, and downloading of past statements. I also recently started using them as my broker, and have to say I'm also quite happy with their web interfaces for doing this as well.
I can access my deposit accounts, money market, credit card, and investment portfolio (including executing trades) via the web, and haven't ever had a problem doing this under Linux. My investment advisor from the regional branch (a couple blocks down the road from my office) is even quite familiar with Linux. They do use a little Javascript on some of the sites, but they have done a very good job at making sure it works under all the various platforms.
Anywho, just thought I'd toss that in for anyone in the East Cost U.S. looking for a reputable bank that has full Linux support for all the online banking/investment functions.
I've been very happy with my PalmVx with the OmniSky wireless modem. I think the OmniSky comes out of the public beta very soon (as in a month or so).
While it's not terribly cheap ($300 for the modem), the service will be a flat monthly rate, regardless of the amount of traffic, and works over AT&T's digital network which covers pretty much the whole country.
It comes standard with e-mail (up to 6 POP accounts, with automatic polling & notification (via a red LED on the front of the modem)), web browser (including graphics if you want to wait for them to download), stock (E*Trade), weather (Weather Channel), traffic (Etak), directions (via MapQuest) and any other web-clipping app you sync to your Palm.
The modem itself is only 19.2Kbps, but that's more than enough to download my e-mail when I'm stuck in traffic on the Beltway. You would be very tight for space if you try it with a regular 2MB Palm V, since the OmniSky software uses 1MB on the Palm.
Overall, I've been really happy with it, if for no other reason than it looks infinitely better than the Palm VII. The modem fits right in with the sleek design of the Palm V series.
OmniSky's website is, surprisingly enough, http://www.omnisky.com/
However, our site is very heavy on the dynamic content (and uses a lot of SSL for the ordering system).
The machine could handle about 20 minutes of the /. effect at a time before the CPU time went sky high. Luckily, we were able to bring the machine down, put in a second processor and double the memory (we also updated mod_perl); and get the machine back up in a couple hours with the new configuration.
The machine has been running like an absolute champ for the past few days. It's been able to handle requests numbering in the millions (page hits are in the hundreds of thousands, but our site uses a fair amount of graphics also) and has transferred several GBs of data just this weekend. If you do anything securely (SSL), keep in mind that anything on that secure page will take up about 7 to 8 times the CPU time as a non-secure item. And never, never, never run a site using Perl for dynamic content without installing mod_perl for Apache. The difference between a machine with it and one without it is tremendous (especially in memory usage).
One thing you can do for big gains in speed is disable hostname lookups (this makes a huge difference when being slashdotted). Also, turn the log level down on Apache. Because we have space to spare on this particular machine, we have the logging set at a moderate level. After two days since the mention on Slashdot, the logs are a few hundred MB. Not a problem if you have the disk space, but if you don't it will be a major problem.
Anyway, the configuration now is: dual PII-450, 256MB of ECC PC100 SDRAM, 10MB Ethernet on kernel 2.2.12 running Apache 1.3.9 and Perl 5.005 (along with the latest OpenSSL, SSLeay and mod_perl). It's having no problem keeping up with the load at this point, and the traffic is still pretty heavy.
-Jon