While water may be the best way to rehydrate oneself (I'm making an effort to drink more of it), I find that it does very little to slake my thirst. At restaurants I will typically throw down 4-5 glasses and I'll still feel as thirsty as when I started.
Sadly, the most effective beverage for quenching my thirst is soda. Coke in particular. Luckily, when I started exercising regularly I realized that it might be unhealthy to counter the water loss with a giant bottle of Coke.
If you're talking Berkeley, California, I like to go to Vik Importers. It's next to Vik's Chaat Corner (great Indian fast-food) at Allston and 4th. They've got a wide variety of spices and dal for really low prices. There are so many Indian-owned businesses in Berkeley that there must be other options near you as well.
I recommend buying whole spices wherever possible. If you have a frying pan and a spare coffee grinder, you can toast and grind spice mixes right before you use them.
You can buy ghee, as well, but it looks so disgusting in the jar that I just make my own.
True, though most users will only change their passwords when the login prompt forces them to (after password expiration). The C-A-D thing is mostly a legacy issue, anyway, and most of the really bad things in the Windows UI are holdovers from previous versions. In Unix GUIs, of course, everything is a legacy issue.
I've managed to make a pretty solid (and enjoyable) living by underestanding computers and networks better than the majority of the population. I do not, however, mistake technical competence for intelligence. There are plenty of people who are smarter and better educated than me whom I would advise to get a Mac or Windows box rather than worrying about the inner workings of Linux.
I like to have it both ways. Middle-click is great for copying snippets of text between terminal windows, and is what I normally use with pure text editors. Mac-style clipboards are better for more complex applications, and are essential for non-text data. Plus they let you paste over a selection.
Anyway, the X-style copy-paste works fine, so it can just be left as it is. But the GUI toolkit developers (primarily GTK+/GNOME, Qt/KDE, Mozilla and OpenOffice) need to do a better job of ensuring advanced clipboard interoperability.
The one time you really need to hit C-A-D in Windows (NT/2000/XP) is when you're logging in. And there's a message right in the middle of the screen telling you to do it.
It should be easy for him to write a config tool that would be usable by himselef and maybe other driver developers. In some ways, building a *good* GUI tool is harder than kernel hacking.
If rolling your own tools were really that attractive an option, we'd probably all ditch Linux and write our own kernels.
You're right, but I think the way Linux is developed (mostly due to Linus' preferences) does feed the binary incompatibility problem. If Linux kernel development were driven by market requirements and disciplined software development managers, then driver compatibility would be a given. Of course, in that case half of the kernel developers would fork the kernel because they weren't having any fun.
I have not found this to be the case with enterprise vendors and customers who pay for real support. When you have access to the vendor's engineers (not just the front-line tech support drones), you can get answers to problems that would completely stump an outsider.
If you ring up Sun with a Platinum support call for an E15K, I can pretty much guarantee that they won't start by telling you to "restore the system".
The main advantage to having a single point of contact for this sort of support is that you have a better shot at accessing the expertise (though usually indirectly) of the primary maintainers of a given piece of code. IBM is probably well equipped to deal with a wide range of Linux problems, but there will definitely be times when the best resource is someone at SGI, HP or some random university. This advantage is largely mitigated by the widespread availability of sourcecode, but it could still be significant when you need answers right now.
More importantly, a given binary driver will work the same way across multiple revisions of Windows 98 (for example). Applying a service pack doesn't break binary compatibility. From a user perspective, the equivalent would be to have Linux drivers that will work with any Red Hat 7.x release.
That sounds like the (lame, IMO) arguments for not stabilizing binary driver APIs in the kernel. Has it occurred to anyone that there are those of us who like to be able to compile from source but would rather use binaries for most installs? Making binaries harder to use does nothing to promote Open Source. A more reasonable tactic would be to send ESR to the homes of people who use binary RPMs and leave him there until they agree to build everything from CVS checkouts.
Why would users thank him for switching them to a web application? Web apps are nice for the IT group (being easier to deploy), but they're not nearly as usable as a good client GUI. And normal business users seem to have a really easy time with small, Access-based apps.
OS/2 2.0 marked the first time I actually got excited about an operating system. I had worked with Macs in high school, but could never justify the high cost. I also worked on Unix workstations at Cal, but as a non-CS major I found them to be lacking in usefulness for most of my computing tasks (flashback to writing an English paper with jove). OS/2 offered a bit of everything: a flexible GUI, a decent multithreading kernel, and DOS/Windows compatibility. I joined the cult in the spring of '92 and was immediately hooked.
Some problems were apparent immediately. The Workplace Shell had some really cool ideas, but it was pretty rough around the edges when 2.0 came out. Also, I could only afford 8MB RAM at the time, so I was constantly swapping to disk. I had done a little Windows 3.x programming, so the advantages of the OS/2 32-bit API were really obvious. Unfortunately, nobody bothered to write any software to it.
Then there was the problem that most of the divisions of IBM itself were standing in the way of OS/2 deployment. And Microsoft was just starting to get the hang of its most predatory marketing tactics. During the '93-'95 period, they were masterful at manipulating the press into touting "Cairo" and "Chicago", while shrouding the already available OS/2 Warp with an SEP field. I remember when MS put out a whitepaper explaining that nobody actually needed preemptive multitasking and 32-bit addressing. A couple of years later they had the media giving them credit for inventing those capabilities (scene from one of the home shopping channels: "Preemptive multitasking...only with Windows 95!").
In the meantime, Microsoft kept gradually improving their products until Windows was just good enough for the people using it (though with the preloads, it hardly mattered). OS/2 fell behind in the feature race, and never got out of the gate in application and driver support. Once PC games started coming out exclusively for Windows instead of DOS, OS/2 was completely eliminated from the consumer market. By '98, it couldn't claim any real advantages over NT except possibly a cleaner API.
So now I'm mostly platform-agnostic, but I do try to support Linux and BSD where I can. The free Unix systems have the advantage of not being burdened by old-school IBM marketing, but I still fear that the free software community could make some of the same mistakes that sank OS/2. Open source licensing will keep free platforms from ever being completely lost, but they can fall behind to the point where they become largely irrelevant.
Here's hoping that things go a little differently this time.
Speaking as someone who is steadily approaching most people's definition of "rich", I am perfectly happy to pay a larger share of taxes. All of those government investments in infrastructure and law enforcement are certainly benefitting me more than some subsistence-level factory worker. And besides, most of my wealth can be traced back to the efforts of poor people at some point. I'm certainly not working any harder than I was at my first job (21K a year!).
I used to read the New York Times every day, and it was obvious to me that they are left-leaning on most domestic social issues, split down the middle on international politics, and right-leaning on the subject of corporate power (in that they tend to completely ignore left-wing views on the matter). Of course, the latter is not surprising, seeing how they are a corporate entity themselves.
The point is that what is "obvious" to you is not necessarily obvious to everyone else.
Yes, please. Once I've settled on a stable kernel version, I don't want to upgrade or rebuild it just to add support for some new device. That's like having to install a service pack when you plug your new webcam into a Windows box.
At a bare minimum, I'd like to see driver APIs frozen throughout each "stable" series. That seems to mostly be the case, but it's not guaranteed right now. Then we might start to see Linux driver disks, possibly with source RPMs or some new driver distribution format, bundled with new hardware.
Re:I'll never tourch RPM again if I have too
on
OpenPKG 1.0 Released
·
· Score: 1
Ports is great for maintaining a single machine, but if you're working in a production environment you're going to do the builds on a single master machine and type "make package" afterwards. BSD packages are somewhat lacking compared to the other Unix package systems, but they're quite easy to build and tweak. I only wish there weren't a split between the packages and the core OS. "make world" isn't a very practical solution for production servers.
The main problem with Red Hat package management is poorly built packages and poorly tracked dependencies. That has plenty to do with the number of people building RPMs and very little to do with the overall quality of RPM itself.
There are plenty of computer-related jobs that don't require a lot of programming skill, but I'm not sure whether you'd be interested in them. Systems administration is probably the most obvious. You probably do need to have some programming ability to become a senior sysadmin, but you can get away with just some basic scripting if you plan to follow that track to a management position.
There's also QA, (development) project management, product management, database administration and a host of other related professions you might consider. Understanding programming is helpful in all of them, but you certainly don't have to be an exceptional programmer if you're not actually going to be a programmer. Pay scales vary by field, but you're not going to starve doing any of those jobs. And you don't have to be an MIS/CIS/CS major to do them, though it would help to take some relevant elective courses.
It really depends on the kind of work you're doing. Being lazy and sleep-dependent myself, I've always tried to judge my subordinates by the work they complete rather than the exact hours they spend in the office.
However, there are plenty of times where it's actually very important to have staff members show up on schedule. Maybe it's when a production database goes down at 9:30 am and your senior DBA is at home asleep. Or you're trying to hold a departmental meeting when half of your staff is sharing a pack of cigarettes in front of the building. I do believe in giving people time to go to doctor's appointments and run errands, but I want to know about such exceptions ahead of time so I have time to prepare.
My current company (which is in pure development phase now, so we have it easier) has a good compromise approach. We're expected to put in about eight hours a day in the office, but we can shift those hours around according to our personal needs. We're all expected to be in during the 10a-3p block, so that we can accommodate any needed facetime. That seems to work well for our developers, since they're not really tied to anyone else's needs.
When we launch our product and have a real production environment to maintain, I expect those hours to get a lot longer and stricter. We won't need to have every last person into the office by 8am, but somebody has to be available when a big customer has problems at the crack of dawn. When I've managed live environments in the past, I've tried to show up earlier than any of my subordinates and leave after they're all gone. You can't really ask techies to maintain a responsible working schedule unless you're willing to set an example for them.
I've spent most of my working years as a hiring manager, but I'm still young enough (28) to be partially biased towards the original poster's viewpoint. I did lots of small IT jobs as a teenager, but didn't think of it as a career path until I graduated from college.
When considering candidates, I do try to take all that early experience into account. However, I do not treat it the same way as full-time corporate experience. It's definitely a good thing to get your feet wet while you're a student. It tends to get you exposure to a wider variety of products and technologies than you'll see as an entry-level IT grunt at a big company. Also, the people who get an early start are often the ones who have a self-sustaining love for the technology. Later in life, they tend to need less encouragement to figure things out on their own.
On the other hand, immersion in the real working world provides its own range of experiences. You learn how to fit your work into the company's "big picture" instead of focusing on whatever you think is cool at the moment. You also may get a chance to work with higher-end systems that are simply unavailable to a student doing part-time work. Most importantly, you learn that you're not quite as smart as you originally thought you were. That knowledge tends to make people a lot more cautious, and thus a lot less dangerous.
My ideal candidate has had a few years of both types of experience. I recall that doing IT work as a teenager was very useful for developing my basic skills (particularly troubleshooting). But in those days I tended to be the local computer expert and my choices were rarely questioned. It was easy to get the impression that I was prepared to take on a more serious role at a real corporation. Looking back, there's no way I would have hired myself at the time for the sort of work I do now. In the past few years, I've learned to fear the wunderkind who works with a $500K mission-critical database server as if it were his personal Linux desktop.
For the original poster, I suggest that he definitely mention his early work in his resume. But he should be very careful about claiming it as "work experience", because it's probably not what employers are talking about when they use the term.
Slashdot Mirror
While water may be the best way to rehydrate oneself (I'm making an effort to drink more of it), I find that it does very little to slake my thirst. At restaurants I will typically throw down 4-5 glasses and I'll still feel as thirsty as when I started.
Sadly, the most effective beverage for quenching my thirst is soda. Coke in particular. Luckily, when I started exercising regularly I realized that it might be unhealthy to counter the water loss with a giant bottle of Coke.
If you're talking Berkeley, California, I like to go to Vik Importers. It's next to Vik's Chaat Corner (great Indian fast-food) at Allston and 4th. They've got a wide variety of spices and dal for really low prices. There are so many Indian-owned businesses in Berkeley that there must be other options near you as well.
I recommend buying whole spices wherever possible. If you have a frying pan and a spare coffee grinder, you can toast and grind spice mixes right before you use them.
You can buy ghee, as well, but it looks so disgusting in the jar that I just make my own.
Samba's great (looking forward to 3.0), but Linux doesn't have a particularly good NFS implementation.
Which doesn't change the fact that India does have four times as many people as the US to throw at every problem that comes up.
True, though most users will only change their passwords when the login prompt forces them to (after password expiration). The C-A-D thing is mostly a legacy issue, anyway, and most of the really bad things in the Windows UI are holdovers from previous versions. In Unix GUIs, of course, everything is a legacy issue.
I've managed to make a pretty solid (and enjoyable) living by underestanding computers and networks better than the majority of the population. I do not, however, mistake technical competence for intelligence. There are plenty of people who are smarter and better educated than me whom I would advise to get a Mac or Windows box rather than worrying about the inner workings of Linux.
I like to have it both ways. Middle-click is great for copying snippets of text between terminal windows, and is what I normally use with pure text editors. Mac-style clipboards are better for more complex applications, and are essential for non-text data. Plus they let you paste over a selection.
Anyway, the X-style copy-paste works fine, so it can just be left as it is. But the GUI toolkit developers (primarily GTK+/GNOME, Qt/KDE, Mozilla and OpenOffice) need to do a better job of ensuring advanced clipboard interoperability.
On a typical desktop machine that's basically the same thing.
The one time you really need to hit C-A-D in Windows (NT/2000/XP) is when you're logging in. And there's a message right in the middle of the screen telling you to do it.
It should be easy for him to write a config tool that would be usable by himselef and maybe other driver developers. In some ways, building a *good* GUI tool is harder than kernel hacking.
If rolling your own tools were really that attractive an option, we'd probably all ditch Linux and write our own kernels.
You're right, but I think the way Linux is developed (mostly due to Linus' preferences) does feed the binary incompatibility problem. If Linux kernel development were driven by market requirements and disciplined software development managers, then driver compatibility would be a given. Of course, in that case half of the kernel developers would fork the kernel because they weren't having any fun.
I have not found this to be the case with enterprise vendors and customers who pay for real support. When you have access to the vendor's engineers (not just the front-line tech support drones), you can get answers to problems that would completely stump an outsider.
If you ring up Sun with a Platinum support call for an E15K, I can pretty much guarantee that they won't start by telling you to "restore the system".
The main advantage to having a single point of contact for this sort of support is that you have a better shot at accessing the expertise (though usually indirectly) of the primary maintainers of a given piece of code. IBM is probably well equipped to deal with a wide range of Linux problems, but there will definitely be times when the best resource is someone at SGI, HP or some random university. This advantage is largely mitigated by the widespread availability of sourcecode, but it could still be significant when you need answers right now.
More importantly, a given binary driver will work the same way across multiple revisions of Windows 98 (for example). Applying a service pack doesn't break binary compatibility. From a user perspective, the equivalent would be to have Linux drivers that will work with any Red Hat 7.x release.
I believe that niche is usually referred to as "Everyone."
That sounds like the (lame, IMO) arguments for not stabilizing binary driver APIs in the kernel. Has it occurred to anyone that there are those of us who like to be able to compile from source but would rather use binaries for most installs? Making binaries harder to use does nothing to promote Open Source. A more reasonable tactic would be to send ESR to the homes of people who use binary RPMs and leave him there until they agree to build everything from CVS checkouts.
Why would users thank him for switching them to a web application? Web apps are nice for the IT group (being easier to deploy), but they're not nearly as usable as a good client GUI. And normal business users seem to have a really easy time with small, Access-based apps.
Given that this is Lucent, I think it's pretty much guaranteed that they can't sell it.
OS/2 2.0 marked the first time I actually got excited about an operating system. I had worked with Macs in high school, but could never justify the high cost. I also worked on Unix workstations at Cal, but as a non-CS major I found them to be lacking in usefulness for most of my computing tasks (flashback to writing an English paper with jove). OS/2 offered a bit of everything: a flexible GUI, a decent multithreading kernel, and DOS/Windows compatibility. I joined the cult in the spring of '92 and was immediately hooked.
Some problems were apparent immediately. The Workplace Shell had some really cool ideas, but it was pretty rough around the edges when 2.0 came out. Also, I could only afford 8MB RAM at the time, so I was constantly swapping to disk. I had done a little Windows 3.x programming, so the advantages of the OS/2 32-bit API were really obvious. Unfortunately, nobody bothered to write any software to it.
Then there was the problem that most of the divisions of IBM itself were standing in the way of OS/2 deployment. And Microsoft was just starting to get the hang of its most predatory marketing tactics. During the '93-'95 period, they were masterful at manipulating the press into touting "Cairo" and "Chicago", while shrouding the already available OS/2 Warp with an SEP field. I remember when MS put out a whitepaper explaining that nobody actually needed preemptive multitasking and 32-bit addressing. A couple of years later they had the media giving them credit for inventing those capabilities (scene from one of the home shopping channels: "Preemptive multitasking...only with Windows 95!").
In the meantime, Microsoft kept gradually improving their products until Windows was just good enough for the people using it (though with the preloads, it hardly mattered). OS/2 fell behind in the feature race, and never got out of the gate in application and driver support. Once PC games started coming out exclusively for Windows instead of DOS, OS/2 was completely eliminated from the consumer market. By '98, it couldn't claim any real advantages over NT except possibly a cleaner API.
So now I'm mostly platform-agnostic, but I do try to support Linux and BSD where I can. The free Unix systems have the advantage of not being burdened by old-school IBM marketing, but I still fear that the free software community could make some of the same mistakes that sank OS/2. Open source licensing will keep free platforms from ever being completely lost, but they can fall behind to the point where they become largely irrelevant.
Here's hoping that things go a little differently this time.
Speaking as someone who is steadily approaching most people's definition of "rich", I am perfectly happy to pay a larger share of taxes. All of those government investments in infrastructure and law enforcement are certainly benefitting me more than some subsistence-level factory worker. And besides, most of my wealth can be traced back to the efforts of poor people at some point. I'm certainly not working any harder than I was at my first job (21K a year!).
I used to read the New York Times every day, and it was obvious to me that they are left-leaning on most domestic social issues, split down the middle on international politics, and right-leaning on the subject of corporate power (in that they tend to completely ignore left-wing views on the matter). Of course, the latter is not surprising, seeing how they are a corporate entity themselves.
The point is that what is "obvious" to you is not necessarily obvious to everyone else.
Yes, please. Once I've settled on a stable kernel version, I don't want to upgrade or rebuild it just to add support for some new device. That's like having to install a service pack when you plug your new webcam into a Windows box.
At a bare minimum, I'd like to see driver APIs frozen throughout each "stable" series. That seems to mostly be the case, but it's not guaranteed right now. Then we might start to see Linux driver disks, possibly with source RPMs or some new driver distribution format, bundled with new hardware.
Ports is great for maintaining a single machine, but if you're working in a production environment you're going to do the builds on a single master machine and type "make package" afterwards. BSD packages are somewhat lacking compared to the other Unix package systems, but they're quite easy to build and tweak. I only wish there weren't a split between the packages and the core OS. "make world" isn't a very practical solution for production servers.
The main problem with Red Hat package management is poorly built packages and poorly tracked dependencies. That has plenty to do with the number of people building RPMs and very little to do with the overall quality of RPM itself.
There are plenty of computer-related jobs that don't require a lot of programming skill, but I'm not sure whether you'd be interested in them. Systems administration is probably the most obvious. You probably do need to have some programming ability to become a senior sysadmin, but you can get away with just some basic scripting if you plan to follow that track to a management position.
There's also QA, (development) project management, product management, database administration and a host of other related professions you might consider. Understanding programming is helpful in all of them, but you certainly don't have to be an exceptional programmer if you're not actually going to be a programmer. Pay scales vary by field, but you're not going to starve doing any of those jobs. And you don't have to be an MIS/CIS/CS major to do them, though it would help to take some relevant elective courses.
It really depends on the kind of work you're doing. Being lazy and sleep-dependent myself, I've always tried to judge my subordinates by the work they complete rather than the exact hours they spend in the office.
However, there are plenty of times where it's actually very important to have staff members show up on schedule. Maybe it's when a production database goes down at 9:30 am and your senior DBA is at home asleep. Or you're trying to hold a departmental meeting when half of your staff is sharing a pack of cigarettes in front of the building. I do believe in giving people time to go to doctor's appointments and run errands, but I want to know about such exceptions ahead of time so I have time to prepare.
My current company (which is in pure development phase now, so we have it easier) has a good compromise approach. We're expected to put in about eight hours a day in the office, but we can shift those hours around according to our personal needs. We're all expected to be in during the 10a-3p block, so that we can accommodate any needed facetime. That seems to work well for our developers, since they're not really tied to anyone else's needs.
When we launch our product and have a real production environment to maintain, I expect those hours to get a lot longer and stricter. We won't need to have every last person into the office by 8am, but somebody has to be available when a big customer has problems at the crack of dawn. When I've managed live environments in the past, I've tried to show up earlier than any of my subordinates and leave after they're all gone. You can't really ask techies to maintain a responsible working schedule unless you're willing to set an example for them.
I've spent most of my working years as a hiring manager, but I'm still young enough (28) to be partially biased towards the original poster's viewpoint. I did lots of small IT jobs as a teenager, but didn't think of it as a career path until I graduated from college.
When considering candidates, I do try to take all that early experience into account. However, I do not treat it the same way as full-time corporate experience. It's definitely a good thing to get your feet wet while you're a student. It tends to get you exposure to a wider variety of products and technologies than you'll see as an entry-level IT grunt at a big company. Also, the people who get an early start are often the ones who have a self-sustaining love for the technology. Later in life, they tend to need less encouragement to figure things out on their own.
On the other hand, immersion in the real working world provides its own range of experiences. You learn how to fit your work into the company's "big picture" instead of focusing on whatever you think is cool at the moment. You also may get a chance to work with higher-end systems that are simply unavailable to a student doing part-time work. Most importantly, you learn that you're not quite as smart as you originally thought you were. That knowledge tends to make people a lot more cautious, and thus a lot less dangerous.
My ideal candidate has had a few years of both types of experience. I recall that doing IT work as a teenager was very useful for developing my basic skills (particularly troubleshooting). But in those days I tended to be the local computer expert and my choices were rarely questioned. It was easy to get the impression that I was prepared to take on a more serious role at a real corporation. Looking back, there's no way I would have hired myself at the time for the sort of work I do now. In the past few years, I've learned to fear the wunderkind who works with a $500K mission-critical database server as if it were his personal Linux desktop.
For the original poster, I suggest that he definitely mention his early work in his resume. But he should be very careful about claiming it as "work experience", because it's probably not what employers are talking about when they use the term.