Try the gnokii project for software which can talk to the cell phone.
Then you just need to write some short script to convert your PIM software database to a form gnokii likes. Shouldn't be too hard. And probably someone has already done it.
Actually sink or swim works pretty well. Hire the person, let them sink or swim, fire them if they sink. Real easy. What would you want to drag them along?
And who gives a crap how many bugs person X fixed last year? This isn't a tech support call center. It's engineering. Are you seriously telling me that without some statistics you can't tell who on your team can pull their weight and who can't? It's not rocket science. In fact it's not a science at all. And the sooner you disillusion yourself the sooner you can see your way to reasonable budgets and timelines instead of overinflated corporate boondoggles.
Do you work in aerospace by any chance? Maybe that is where your distorted view arises from. Try a startup now and then to see work getting done at a pace that will get your product to market before your competitor instead of 3 years later...
Well yeah. How could you have software development without some kind of workflow management tool? Of course a piece of paper and a pencil or a spreadsheet will do for small stuff. But I hardly consider it something that takes more than 5 minutes of 'learning'
As far as larger systems, well, I guess you could try teaching that. But if you just gave an intelligent programmer the equivalent of the hippocratic oath "fix it but try not to break anything else" that's about all you can do. After that it's sink or swim and you'll find out very quickly who is worth their salt.
A lot of software work is at a smaller scale. If 60% or so of software's lifecycle is maintenance, and there's a lot of software out there, and also since many software projects are very small, I'd venture to say that process is almost irrelevant for plenty of work.
Being knowledgeable about low level operation of the machine will take you farther, since you won't have the fear of getting down to the bare metal to figure out a problem. And assembly language is important there... but also things like debuggers, protocol sniffers, etc. Anything that lets you get to the bare metal to figure out a problem will get you to a solution quicker.
Process and modern design concepts are important for large projects and at the architectural level.
I already ditched cable... late last year. With all the viruses Adelphia began dropping ping packets. That was the last straw. They also had a policy against VPNs and hosting services of any kind, and enforced the service block by not allowing inbound port 80 packets.
I pay more for DSL but I can do whatever I want with it. Speakeasy just rocks.
1) You drink the corporate cool-aid and start company with big new good idea using expensive Microsoft development tools for one of the Microsoft Platforms 2) Microsoft incorporates implementation of the idea into Humungous Office Application X and doesn't pay you a dime 3) Go out of business
RMS is the Great Man, but if we put in all the slash terms into GNU/Linux that really belong there, Linux would have a name more appropriate for an Ent.
You could be right. But my guess is that Linux will continue to evolve to such a point in 10 years that we won't recognize it as as the Unix work-alike it started out as.
Maybe we'll just drop the term "the OS" and say "The Linux." But since some geeks (like me) may hold on to the idea that Linux is just the kernel, I hope that "The Debian" gets that place instead. It has a good shot since it allows for different kernels which will allows more freedom for innovation of the OS.
On one point: that a company owns the algorithms you may create while in their employ. Not true... they probably own all your code, work product, etc. but algorithms are not protected by copyright. You have to go to the patent system to do that. And what you learn about your art while in someone's employ cannot be taken away from you. You may be enjoined from working in some area for a period of time in exchange for some monetary consideration from a company, but you've got a right to work (the exact definition of which varies from state to state). Now a given company may choose not to hire you to avoid any appearance of impropriety to stave off lawsuits. But you as a programmer usually need not be concerned about that.
Patents are a different issue, but it doesn't have anything to do with secrets. Patents are specifically not secrets. Just like open source code, it is possible to look at patents and tell whether you are infringing. And even if you are, you might go to court and prevail if there is good prior art. (That said algorithm/business model patents are Evil)
On unpublishing the code, that is an interesting issue in this whole IBM/SCO thing. My guess is that if it happened the parties responsible for the initial leak of the proprietary code are the only ones responsible, not end users in any reasonable view a court could take. In the worst case, which Red Hat seems to be covering here, is that the end user could be enjoined from using someone's code.
Wow your company is paranoid... and I'd say abnormally so.
Usually it goes the other way... once you are exposed to Closed source code, you can never be employed writing the same Closed source code for another vendor. Example: BIOS clean room development.
In the open source world, ideas are traded fairly freely. It's easy not to copy someone else's code. It really is. Open source guys really don't care if you copy their ideas. They won't sue you for that. Now your closed source could leak out one day. But that's easy to see since open source code is usually publicly available.
Now if some loser adds some closed source code into an open source code base without permission, it should be treated as a bug and fixed. I think that Red Hat is absolutely doing the right thing here. There's only going to be bits and pieces here and there I would guess... they'll squash them like bugs if they show up.
Now SCO thinks they can sue end users for infringement of their copyright for using Linux. From what I've read on Groklaw they aren't going to have much luck with those cases. Hence the fact that there aren't any such cases yet. Just the IBM suit which is about breach of contract, not copyright.
Fact is, Enterprise has been fairly weak. I've felt since the very beginning of the show that the creators are grasping for audience. The obvious attempts at Star Trek cleansed sexy scenes, this stupid Expanse theme, all aimed at drawing audience "share" but not intellectual junk food us geeks look for and made the other series popular. The way you get audience is by writing good scripts. TNG showed that.
Enterprise has a lot going for it... getting to see the initial meetings with Andoreans, Tellarians, Klingons, Romulans, etc. was really fun, they need to get out of this stupid expanse plotline quick...
DS9 was obviously the best ST. The writing was absolutely phenomenal. The story arcs make for a truly epic saga. If you all really hate Enterprise so much, go buy up the DS9 DVD set and watch it again. It really is the best of all treks. I'm glad they are continuing the storyline from DS9 in the books into the future.
TOS has a place in my heart, but it was pretty campy though it had some good moments. It's classic. And everyone can just STFU about the Enterprise Klingons not looking like TOS Klingons. Is it so hard to understand that a goatee isn't going to make a convincing Klingon these days? Tards...
Voyager sucked. That's an empirical fact. Cheesiest dialog (even worse than TOS) and huge plot holes.
TNG was a great show once it got it's legs. It was a lot more timid than DS9, but I think it's definitely the second best trek.
A search engine is a way of finding information related to search terms. If I typed "playboy" into a search engine, it would be obvious I was looking for pr0n. Period. It is the search engine's job to give me results in that category.
Everybody by now knows the difference between the line in google where you type search terms and the URL line. Totally different things. If I go to playboy.com I expect to see things from that company. If I type it into a search engine, I expect to find things related to the term, in this case I am expecting to find sites which provide content LIKE that company does.
This wouldn't cause any confusion in the marketplace.
Fry's has a sub $100 multi-format unit no rebate required.
$90 (I got one on Thanksgiving sale for $80).
Burns DVD-R, DVD+R, DVD-RW, DVD+RW.
I bought one, and I have it working with Debian. I could only record on DVD-R with growisofs, not dvdrecord or cdrecord-prodvd.
Some things I've learned about DVD-R: 1. Don't buy a lot of media till you know it will work. Most of these devices have genuine media compatibility problems. The firmware has to be tuned to each manufacturer's materials. That is, each DVD media has a MID code and if the firmware for the burner doesn't recognize it, it'll probably be incompatible until the next firmware update. If you buy a DVD burner, go to their web site and look at their media compatibility list. I mean it. If you pay $80 for a burner then pay $50 for 50 discs that don't work, well, not much of a bargain. 2. Make sure the recordable media plays in your dvd player if you want to backup your dvd movies 3. Note that typical off the shelf DVD movies are dual layer. They won't fit on a DVD-R, you need to use tools to split them. Rip it with dvdbackup, split it with GOPchop, build the directory structure and TOC files with dvdauthor, build the image with mkisofs and burn it with growisofs (from latest rev of k3b). Hmm... seems it would be a nice project to connect these things together with a Python script (unfortunately 'splitting' the dvd seems to be an unavoidably manual process).
BTW the Emprex cheapo drive is actually the same as the BTC 1004.
What idiot would take their printer in for service with a third party cartridge in it?
Pop out third party cartridge, take it in for service, don't volunteer the information. Assuming the firmware isn't storing info about what cartridge you use (which it probably doesn't... flash chips cost $$$ and hardware manufacturing is alll about lowering the total COG)
Any computer person should understand the problem here: SSN is the USERNAME, not the PASSWORD. But it is being used as a password.
SSN does what is supposed to do just fine. It is a unique name (or ID, if you wish... a string is a string is a string...). It should not be considered a password.
Simple solution... SSP, Social Security Password, which the gubmint can require only to be stored as a hash or encrypted. That would raise the bar a lot.
-- John.
I agree 100%. But at that point we have gone beyond the issue I was responding to (i.e. that type-safe languages can prevent array indexing errors).
There are few Languages that will prevent array indexing errors. But even in straight C I can come up with methods, or libraries which if used in lieu of direct access would never index outside of array bounds or raise an exception.
So, rather than switch languages, we just put the work back on the programmer to get it right by design not hope the compiler will save him/her.
Most strongly typed languages let you use an integer to index into an array, and don't force you to create an integer subtype which is appropriately sized to the array. So you will get run-time errors.
You aren't likely to get a segmentation fault with such languages, but the program still fails with an exception. And if it doesn't blow up, it may just end up hobbling along pretending things are OK.
Yeah, I owe the Coco, Coco 2 and 3 a lot... how do kids learn how to program today without "Getting Started With Color BASIC?", and typing in listings from Rainbow Magazine?
Yeah, the problem is that game programmers let this happen to them. They take the job because they love to write games. So in the gaming industry the "producers" (management) take due advantage of the "talent" (artists, programmers, designers). Particularly the programmers.
In fact, game development is one of the most demanding types of software development. It calls on a wide range of knowledge (or at least ability to "look it up") from math and physics to programming techniques typical of embedded systems development (to maximize speed).
But embedded developers typically get paid twice as much.
So what you get is an industry full of kids willing to work for pennies. When they grow up, and need to pay a morgage, support wife and kids, etc., they sign up for a boring job leveraging MSSQL, and VB.
As programmers in the gaming industry get treated more and more like unskilled labor, the answer becomes obvious: organize. Unfortunately, what we'll probably see is just a bunch of scabs willing to work for fun.
I guess I didn't notice the transition. It used to be "there's no apps for Linux." Now Linux is showing up Windows since "out of the box" it's actually usable because of all the apps bundled with it.
Whereas with Windows you have to dig for Free instead of just Stolen.
Slashdot Mirror
Try the gnokii project for software which can talk to the cell phone.
Then you just need to write some short script to convert your PIM software database to a form gnokii likes. Shouldn't be too hard. And probably someone has already done it.
Actually sink or swim works pretty well. Hire the person, let them sink or swim, fire them if they sink. Real easy. What would you want to drag them along?
And who gives a crap how many bugs person X fixed last year? This isn't a tech support call center. It's engineering. Are you seriously telling me that without some statistics you can't tell who on your team can pull their weight and who can't? It's not rocket science. In fact it's not a science at all. And the sooner you disillusion yourself the sooner you can see your way to reasonable budgets and timelines instead of overinflated corporate boondoggles.
Do you work in aerospace by any chance? Maybe that is where your distorted view arises from. Try a startup now and then to see work getting done at a pace that will get your product to market before your competitor instead of 3 years later...
Well yeah. How could you have software development without some kind of workflow management tool? Of course a piece of paper and a pencil or a spreadsheet will do for small stuff. But I hardly consider it something that takes more than 5 minutes of 'learning'
As far as larger systems, well, I guess you could try teaching that. But if you just gave an intelligent programmer the equivalent of the hippocratic oath "fix it but try not to break anything else" that's about all you can do. After that it's sink or swim and you'll find out very quickly who is worth their salt.
I suppose you use a 2 digit hex display, a jog dial and an enter-key to program with?
A lot of software work is at a smaller scale. If 60% or so of software's lifecycle is maintenance, and there's a lot of software out there, and also since many software projects are very small, I'd venture to say that process is almost irrelevant for plenty of work.
Being knowledgeable about low level operation of the machine will take you farther, since you won't have the fear of getting down to the bare metal to figure out a problem. And assembly language is important there... but also things like debuggers, protocol sniffers, etc. Anything that lets you get to the bare metal to figure out a problem will get you to a solution quicker.
Process and modern design concepts are important for large projects and at the architectural level.
The OS calls available are different from other platforms, obviously.
Also, more importantly, the syntax of the GNU assembler is very different if you're used to the Intel syntax.
-- John.
I already ditched cable... late last year. With all the viruses Adelphia began dropping ping packets. That was the last straw. They also had a policy against VPNs and hosting services of any kind, and enforced the service block by not allowing inbound port 80 packets.
I pay more for DSL but I can do whatever I want with it. Speakeasy just rocks.
Reality:
1) You drink the corporate cool-aid and start company with big new good idea using expensive Microsoft development tools for one of the Microsoft Platforms
2) Microsoft incorporates implementation of the idea into Humungous Office Application X and doesn't pay you a dime
3) Go out of business
RMS is the Great Man, but if we put in all the slash terms into GNU/Linux that really belong there, Linux would have a name more appropriate for an Ent.
The change will be so gradual you won't even notice it.
But I'm sure you'll still be able to
apt-get install curmudgeonly-cli-environment
And be perfectly happy even then...
You could be right. But my guess is that Linux will continue to evolve to such a point in 10 years that we won't recognize it as as the Unix work-alike it started out as.
Maybe we'll just drop the term "the OS" and say "The Linux." But since some geeks (like me) may hold on to the idea that Linux is just the kernel, I hope that "The Debian" gets that place instead. It has a good shot since it allows for different kernels which will allows more freedom for innovation of the OS.
On one point: that a company owns the algorithms you may create while in their employ. Not true... they probably own all your code, work product, etc. but algorithms are not protected by copyright. You have to go to the patent system to do that. And what you learn about your art while in someone's employ cannot be taken away from you. You may be enjoined from working in some area for a period of time in exchange for some monetary consideration from a company, but you've got a right to work (the exact definition of which varies from state to state). Now a given company may choose not to hire you to avoid any appearance of impropriety to stave off lawsuits. But you as a programmer usually need not be concerned about that.
Patents are a different issue, but it doesn't have anything to do with secrets. Patents are specifically not secrets. Just like open source code, it is possible to look at patents and tell whether you are infringing. And even if you are, you might go to court and prevail if there is good prior art. (That said algorithm/business model patents are Evil)
On unpublishing the code, that is an interesting issue in this whole IBM/SCO thing. My guess is that if it happened the parties responsible for the initial leak of the proprietary code are the only ones responsible, not end users in any reasonable view a court could take. In the worst case, which Red Hat seems to be covering here, is that the end user could be enjoined from using someone's code.
Wow your company is paranoid... and I'd say abnormally so.
Usually it goes the other way... once you are exposed to Closed source code, you can never be employed writing the same Closed source code for another vendor. Example: BIOS clean room development.
In the open source world, ideas are traded fairly freely. It's easy not to copy someone else's code. It really is. Open source guys really don't care if you copy their ideas. They won't sue you for that. Now your closed source could leak out one day. But that's easy to see since open source code is usually publicly available.
Now if some loser adds some closed source code into an open source code base without permission, it should be treated as a bug and fixed. I think that Red Hat is absolutely doing the right thing here. There's only going to be bits and pieces here and there I would guess... they'll squash them like bugs if they show up.
Now SCO thinks they can sue end users for infringement of their copyright for using Linux. From what I've read on Groklaw they aren't going to have much luck with those cases. Hence the fact that there aren't any such cases yet. Just the IBM suit which is about breach of contract, not copyright.
I want Enterprise to succeed.
Fact is, Enterprise has been fairly weak. I've felt since the very beginning of the show that the creators are grasping for audience. The obvious attempts at Star Trek cleansed sexy scenes, this stupid Expanse theme, all aimed at drawing audience "share" but not intellectual junk food us geeks look for and made the other series popular. The way you get audience is by writing good scripts. TNG showed that.
Enterprise has a lot going for it... getting to see the initial meetings with Andoreans, Tellarians, Klingons, Romulans, etc. was really fun, they need to get out of this stupid expanse plotline quick...
DS9 was obviously the best ST. The writing was absolutely phenomenal. The story arcs make for a truly epic saga. If you all really hate Enterprise so much, go buy up the DS9 DVD set and watch it again. It really is the best of all treks. I'm glad they are continuing the storyline from DS9 in the books into the future.
TOS has a place in my heart, but it was pretty campy though it had some good moments. It's classic. And everyone can just STFU about the Enterprise Klingons not looking like TOS Klingons. Is it so hard to understand that a goatee isn't going to make a convincing Klingon these days? Tards...
Voyager sucked. That's an empirical fact. Cheesiest dialog (even worse than TOS) and huge plot holes.
TNG was a great show once it got it's legs. It was a lot more timid than DS9, but I think it's definitely the second best trek.
I agree with the previous court, and here's why:
A search engine is a way of finding information related to search terms. If I typed "playboy" into a search engine, it would be obvious I was looking for pr0n. Period. It is the search engine's job to give me results in that category.
Everybody by now knows the difference between the line in google where you type search terms and the URL line. Totally different things. If I go to playboy.com I expect to see things from that company. If I type it into a search engine, I expect to find things related to the term, in this case I am expecting to find sites which provide content LIKE that company does.
This wouldn't cause any confusion in the marketplace.
-- John.
Fry's has a sub $100 multi-format unit no rebate required.
$90 (I got one on Thanksgiving sale for $80).
Burns DVD-R, DVD+R, DVD-RW, DVD+RW.
I bought one, and I have it working with Debian. I could only record on DVD-R with growisofs, not dvdrecord or cdrecord-prodvd.
Some things I've learned about DVD-R:
1. Don't buy a lot of media till you know it will work. Most of these devices have genuine media compatibility problems. The firmware has to be tuned to each manufacturer's materials. That is, each DVD media has a MID code and if the firmware for the burner doesn't recognize it, it'll probably be incompatible until the next firmware update. If you buy a DVD burner, go to their web site and look at their media compatibility list. I mean it. If you pay $80 for a burner then pay $50 for 50 discs that don't work, well, not much of a bargain.
2. Make sure the recordable media plays in your dvd player if you want to backup your dvd movies
3. Note that typical off the shelf DVD movies are dual layer. They won't fit on a DVD-R, you need to use tools to split them. Rip it with dvdbackup, split it with GOPchop, build the directory structure and TOC files with dvdauthor, build the image with mkisofs and burn it with growisofs (from latest rev of k3b). Hmm... seems it would be a nice project to connect these things together with a Python script (unfortunately 'splitting' the dvd seems to be an unavoidably manual process).
BTW the Emprex cheapo drive is actually the same as the BTC 1004.
What idiot would take their printer in for service with a third party cartridge in it?
Pop out third party cartridge, take it in for service, don't volunteer the information. Assuming the firmware isn't storing info about what cartridge you use (which it probably doesn't... flash chips cost $$$ and hardware manufacturing is alll about lowering the total COG)
Any computer person should understand the problem here: SSN is the USERNAME, not the PASSWORD. But it is being used as a password. SSN does what is supposed to do just fine. It is a unique name (or ID, if you wish... a string is a string is a string...). It should not be considered a password. Simple solution... SSP, Social Security Password, which the gubmint can require only to be stored as a hash or encrypted. That would raise the bar a lot. -- John.
Yeah, but it's so much more exciting to think of my Dad's printing presses as Robots...
Heidelberg: Danger! Danger! Paper Misfeed! Human assistance required!
-- John.
I agree 100%. But at that point we have gone beyond the issue I was responding to (i.e. that type-safe languages can prevent array indexing errors).
There are few Languages that will prevent array indexing errors. But even in straight C I can come up with methods, or libraries which if used in lieu of direct access would never index outside of array bounds or raise an exception.
So, rather than switch languages, we just put the work back on the programmer to get it right by design not hope the compiler will save him/her.
Well, sort of...
Most strongly typed languages let you use an integer to index into an array, and don't force you to create an integer subtype which is appropriately sized to the array. So you will get run-time errors.
You aren't likely to get a segmentation fault with such languages, but the program still fails with an exception. And if it doesn't blow up, it may just end up hobbling along pretending things are OK.
2 CD's is just about the amount of space you need to hold a good quality conversion of a DVD to DIVX format.
And since CD's are so much cheaper than recordable DVD's, it seems like a good way to back up a DVD collection cheaply.
Yeah, I owe the Coco, Coco 2 and 3 a lot... how do kids learn how to program today without "Getting Started With Color BASIC?", and typing in listings from Rainbow Magazine?
Yeah, the problem is that game programmers let this happen to them. They take the job because they love to write games. So in the gaming industry the "producers" (management) take due advantage of the "talent" (artists, programmers, designers). Particularly the programmers.
In fact, game development is one of the most demanding types of software development. It calls on a wide range of knowledge (or at least ability to "look it up") from math and physics to programming techniques typical of embedded systems development (to maximize speed).
But embedded developers typically get paid twice as much.
So what you get is an industry full of kids willing to work for pennies. When they grow up, and need to pay a morgage, support wife and kids, etc., they sign up for a boring job leveraging MSSQL, and VB.
As programmers in the gaming industry get treated more and more like unskilled labor, the answer becomes obvious: organize. Unfortunately, what we'll probably see is just a bunch of scabs willing to work for fun.
-- John.
Never thought you'd hear that?
I guess I didn't notice the transition. It used to be "there's no apps for Linux." Now Linux is showing up Windows since "out of the box" it's actually usable because of all the apps bundled with it.
Whereas with Windows you have to dig for Free instead of just Stolen.
-- jhoger