I've found that there's little compromise in the Treo for either phone or PDA work. I went from a IIIc to a Treo 180 and the only thing I really miss is the grafiti area (which is an option).
The phone UI is quite good. I liked what I had on the 8290, but it's a lot easier to see the limitations I had over there when I moved away from them. My caller ID now shows the full name and phone number (and which of that person's numbers it is). When I miss a call, it lets me know who I missed (right now it's showing me the ``You missed a call.'' screen with the name, which number (W), the actual phone number, and the date. Under this there are two buttons, ``OK'' and ``call back.''
And damnit, I've got a mobile speakerphone now.
I'm only keeping one addressbook. I realized that the one on my phone and the one on my palm had been growing apart when I looked through my old phone last night to make sure everyone I called was in the palm.
I now have direct wireless internet access rather than having to line my phone and palm up use IR to dial (which is actually harder than it sounds).
I have one clock to set instead of three, and I set it via ntp last night.
Overall, I don't think I gave up very much at all, but I got a lot in return.
I had trouble finding one yesterday. I tried a demo in Frys, liked it, and went some place to buy it (I think they had them there, but I didn't want to even ask if they offered activation).
I went to a local Cingular shop, and they said they didn't have any, and recommended I go to The Good Guys.
I went to The Good Guys and while I was talking to one guy who said they didn't have any, another guy looked in their database and said that they had *one*. I have that one now.:)
I've been carrying a Palm, Nokia 8290 and a Motorola P935. I've still got the pager, but I'm getting rid of that soon.
In my experience, relying on the internet for API documentation leaves a lot of developers with nothing to do when there's a problem getting to the site that contains the documentation. This happened once when one of our developers who hosted a very significant amount of the documentation we used at his house and then left for Mexico for a week and had a machine die. The source was available in a few other places on the net, but most people would rather complain about all of the links being broken than look around for a mirror.
We host all API documentation on internal machines nowadays.
I don't have a phone line anywhere near my TiVo. The four ethernet jacks in that room are full, and the only serial port near it is collection telemetry data. When my TiVo needs to dial up (like it does now), I run a phone cord halfway across my house and tell it to dial. If it could hop on the 802.11b LAN, my life would be a lot easier.
I'll send in my $200. I've already given them a lot of money in monthly fees, and I don't see myself discarding this box (which is the main reason I didn't do the lifetime subscription in the first place.
Besides, this is a company I'd really like to stay around, so I'm not going to bet against them.
While it may sound neat to say, ``go ahead, try to telnet to 10.200.120.4,'' it doesn't exactly work that way.
Does this machine on 10.200.120.4 have the ability to make direct outbound connections? Assuming yes, does you realize that the only difference between an inbound connection and an outbound connection is who sent the first packet?
Many people tend to believe that the *only* security risk they have to worry about is inbound SYN packets, so they base their entire security policy on stopping bad inbound packets. The last two sites I broke into, I did so by tricking a machine to come to me. Just for humor, here are the two scenarios:
The first one was quite a while ago, and I did it at contract. A co-worker found a potential hole in a CGI, but nobody took it seriously. By sending the right data through the CGI, I found that I could make it execute arbitrary commands. First, I did some basic stuff (id; ls -lR/; etc...) and had it output the mail to me (couldn't see the output from the CGI). I figured out the web server user had a shell and a writable home directory, and the machine had ssh (client and server installed). I generated a private key and had it mail me the public version of that key, then I added it to my authorized_keys and installed my public key in the web server's authorized_keys. Then I had the web server user ssh to my host with remote port forwarding back into the web server's 22. ssh -p 2222 localhost and I'm sitting in a shell on the web server (192.168.something).
The next time I saw something like this, it was out in the wild. There was a web server that was running a CGI that *seemed* like it was probably just handing the input over to a command, so I gave it a shot. This time, the web server didn't have a usable home directory, so the ssh thing was out, but it did have X installed, so I fired up a VNC server, opened it to the world and opened an xterm up in it. Before too long, I had an entire X desktop running on some guy's web server. I sent the local admin an E-mail (through pine) letting him know what was wrong and recommending he fix it before someone meaner than I am comes along.
Anyway, point of the story. Having an unroutable IP address is good internet security as long as you keep it unrouted. Once you give the thing direct internet access, the unroutability of it becomes much less relevant.
Re:Employee surfing - hard learned lessons
on
Peek-a-Boo(ty)
·
· Score: 1
I find it ridiculous that people believe it is their right to use company resources however they want. Basically, the more people can do with their computers on a public network, the higher the risk of something horrible happening because of this.
It's always a big conflict. They want employees to be really happy and feel like they can do whatever they want, but when something bad happens, they come and ask why and who. The discussions are always essentially, ``Is there any way we can keep people from doing bad things without preventing them from doing bad things?''
It's just stupid. They don't get TVs on their desks they can sit around and watch. They don't assume it's OK to spend a couple hours a day talking on the phone. They certainly don't think it's OK to bring one of their friends in and hang out all day.
There is a real risk here, and we've had to clean up after plenty of people who downloaded an app that broke their machines, leaked confidential information, harrassed people, etc... all using our resources. It's not like very many people actually need Internet access above local E-mail.
There are so few jobs where people even get internet access that it seems even more bizarre when people think of it as a fundamental job right.
I've not seen a comprehensive list of companies Microsoft has killed, but I was working with a guy from Quarterdeck who told me about how MS killed them.
Quarterdeck produced QEMM, which any old-school DOS users should remember as the best memory management system available at the time. MS wanted it, and offered to buy the company. The company did not want to sell. MS put in an a very large order for boxed copies of QEMM. Quarterdeck took out short-term loans to fill the order, and when they were ready to ship, MS cancelled. There goes a competitor.
I'm sure there are lots of stories like this we haven't heard.
I've been to a Wal-Mart twice since I moved away from Arkansas (it was my local grocery store). I can get the same products from other vendors, sometimes for more money, sometimes for less.
When was the last time someone told you that you *had* to purchase a telephone from Wal-Mart before you were allowed to talk to him?
I *just* finished my FreeBSD 4.5 upgrade on my database server last weekend. It was a big effort, as I've got multiple databases with tables ranging from a few to 7 million rows with referential integrity and average at least 1 insert every ten seconds every day.
Every bit of code I write goes into CVS. My CVS repository is not open to the public, it's to help me track my own code. It gives me the freedom to make arbitrary experimental changes, toss them into a branch (or just throw them away and roll back my code), examine the difference between any two arbitrary dates for any two files, etc... It gives me an excellent history of development, per file, so I can know what I've done, when I did it, etc...
What it does *not* do, however, is encourage anyone to submit patches any more than they otherwise would. It's not voodoo. People don't hear that someone's using proper development tools and start spewing code generators at them.
If some guy allowed lots of people to dump code directly into his source tree, then, yeah, it's going to have as much crap as exists with the incoming patches nowadays, possible more. The solution isn't to avoid CVS, it's to not use it in really stupid ways. That's roughly the equivalent of saying, ``Linux development shouldn't happen under Linux because it's a multi-user OS and just anyone could be logged in changing the code at any given moment!'' Yep.
Now granted, that won't solve the immediate problem much like inflating your tires won't give you enough gas to start your car...but when you have two problems, why not solve them both?
Yes, it's true that it's not easy to revert bad stuff with CVS. It's not any easier without it. It's most certainly possible, though, especially if you were to tag every patch import.
Don't take development tool advice from someone who won't use the tools because they cause problems when you use them incorrectly.
I've been in enough situations where an application implemented by someone who didn't think through the design clearly enough had to be rewritten to meet new fundamental requirements, or, in some cases, to even work.
I don't believe that any actual programmers (i.e. the people who occasionally state they need to rewrite something) would make such a statement. As delicate as software is these days, it shouldn't be too much of a stretch to assume that some things cannot be repaired. Often, a prototype is thrown together as a proof-of-concept and needs to have its functionality designed to fit into a proper application, but instead, stuff just keeps getting glued onto the original prototype.
In a recent case, I had a very large application that was written in perl. It performed very badly and was all but impossible to extend. The business specification for the next version of the application included a lot of functionality we would not be able to add to the existing code base. We determined that we could, more quickly, create an entirely new code base in a new language that included all of the new functionality and all of the old functionality that was actually still used faster than we could've retrofitted the new requirements into the old code. We did.
It's ridiculous to think that the sum of work of a ton of junior programmers makes up an implementation that's worth retaining simply because it's there.
Re:how different (from standard netbsd) is it?
on
Debian NetBSD
·
· Score: 2, Informative
Or have they moved to a Sys V init system
This would be a pretty big step backwards. The NetBSD startup stuff is far superior to SysV. They wanted to move to a similar model for a while, but anyone who's ever used SysV startup on a real system understands the problems.
Their current system allows you to drop files in a directory for startup that contain no special file names. They may list internally what service they provide, and what service they require and they will be sequenced properly. If you run two things that require network and don't provide anything that anything else requires, they'll get run after the network portion of the startup runs. There is no special shell scripting based on requested command (i.e. how many SysV startup scripts have you seen that implement ``start'' but not ``stop?''). Best thing is they're tiny, and they grow with the system. You define a couple variables and then do ``run_rc_command "$1"''
I think it's cool that people are trying different things, and I don't care as long as it's not wasting me money, but they'd probably be better off learning from a system rather than trying to assimilate the kernel while throwing away the other good stuff.
What does FreeBSD have to do with anything?
on
Debian NetBSD
·
· Score: 2, Informative
Your complaints about NetBSD are a result of your experience with FreeBSD? These are completely different *operating systems* (not kernels, full operating systems).
Windowmaker is not BSD. If you have a problem with Windowmaker, go complain to them.
Which parts of tuning require five years of experience and/or a CS degree? I switched from Linux to NetBSD after I'd been using computers for about two years altogether, and have always found it easier to work with. Why? Because it's a whole operating system. If stuff goes into the kernel, it's released with userland support, all at the same time.
NetBSD is, IMO, the cleanest system out there today. Everything works, and moving forward is easy. Doesn't come with bash? So what? I don't use bash, so I'm pretty happy to not see it. I do like the standard bourne shell it comes with for running my scripts. I do use tcsh, so it's typically one of the first things I install from pkgsrc on a new machine.
``But pkgsrc is hard! You have to build the stuff yourself,'' you say? A ``make package'' at the top level will create binary packages for the current platform for all packages your configuration suggests you're licensed for. Port maintainers typically do this and provide binary packages for most things people would want. In fact, when NetBSD releases ISOs, they release pre-built package ISOs for i386, just to make it a bit quicker (it certainly can't be any easier).
Interesting Linux Mentality
on
Debian NetBSD
·
· Score: 1
For the longest time, people would argue about how Linux isn't an operating system, just a kernel from which an operating system is made. Now people are going out there and taking a complete operating system, pulling a part out of it, and sticking it in the middle of what was normally a Linux distribution.
Linux is a Kernel without an operating system. NetBSD is a complete operating system where everything is designed to work together seamlessly.
The constitution guarantees the freedom of speech. Nobody is arguing that spammers should not be allowed to say what they're saying.
The constitution does not guarantee the right to be heard by the general public.
I, at least, am not complaining about what the spam says, nor do I believe they shouldn't be allowed to advertise their products. My complaint is the amount of effort I have to go through in order to read my own E-mail.
Less than a week ago, I switched DSL providers from one that charged per usage to one that is always flat (i.e. spam no longer appears on my ISP bill). My very next day at work a CS rep was asking me what we can do to get some of the spam out of our customer service queues as our customer service representatives (many of whom are apparently Mormon) are spending more time (money) processing porn spam than customer requests.
I wrote mailfw the second time we had a problem like this. At my company, it's plucked attachments from 12,823 mails since June 2000.
It sounds fairly similar, examine every attachment recursively and check both the file extensions and the mime types against a lists, pull the bad content, and deliver the message with a note at the top that lists the things that were removed and why. 18 months without hearing about *that* problem.
Actually, it was pretty close. With contributions to my ``kittycode'' project, it's possible to pull up books at Amazon by ISBN, and other products by UPC if you've got a place that'll give you info by UPC. Look here.
Slashdot Mirror
Apparently you haven't seen Antitrust.
I've found that there's little compromise in the Treo for either phone or PDA work. I went from a IIIc to a Treo 180 and the only thing I really miss is the grafiti area (which is an option).
The phone UI is quite good. I liked what I had on the 8290, but it's a lot easier to see the limitations I had over there when I moved away from them. My caller ID now shows the full name and phone number (and which of that person's numbers it is). When I miss a call, it lets me know who I missed (right now it's showing me the ``You missed a call.'' screen with the name, which number (W), the actual phone number, and the date. Under this there are two buttons, ``OK'' and ``call back.''
And damnit, I've got a mobile speakerphone now.
I'm only keeping one addressbook. I realized that the one on my phone and the one on my palm had been growing apart when I looked through my old phone last night to make sure everyone I called was in the palm.
I now have direct wireless internet access rather than having to line my phone and palm up use IR to dial (which is actually harder than it sounds).
I have one clock to set instead of three, and I set it via ntp last night.
Overall, I don't think I gave up very much at all, but I got a lot in return.
I had trouble finding one yesterday. I tried a demo in Frys, liked it, and went some place to buy it (I think they had them there, but I didn't want to even ask if they offered activation).
:)
I went to a local Cingular shop, and they said they didn't have any, and recommended I go to The Good Guys.
I went to The Good Guys and while I was talking to one guy who said they didn't have any, another guy looked in their database and said that they had *one*. I have that one now.
I've been carrying a Palm, Nokia 8290 and a Motorola P935. I've still got the pager, but I'm getting rid of that soon.
Whoops, meant to hit preview and accidentally hit submit. There should be another echo in there:
echo 'echo "Hey, look into upgrading Apache on this host."' | at now + 2 months
at is a perfect tool for this. No software modifications need to take place, people can use it any time they want, etc...
Example:
echo "Hey, look into upgrading Apache on this host." | at now + 2 months
Ma Bell + Public Utilities Commission == Mother PUC?
In my experience, relying on the internet for API documentation leaves a lot of developers with nothing to do when there's a problem getting to the site that contains the documentation. This happened once when one of our developers who hosted a very significant amount of the documentation we used at his house and then left for Mexico for a week and had a machine die. The source was available in a few other places on the net, but most people would rather complain about all of the links being broken than look around for a mirror.
We host all API documentation on internal machines nowadays.
I don't have a phone line anywhere near my TiVo. The four ethernet jacks in that room are full, and the only serial port near it is collection telemetry data. When my TiVo needs to dial up (like it does now), I run a phone cord halfway across my house and tell it to dial. If it could hop on the 802.11b LAN, my life would be a lot easier.
I'll send in my $200. I've already given them a lot of money in monthly fees, and I don't see myself discarding this box (which is the main reason I didn't do the lifetime subscription in the first place.
Besides, this is a company I'd really like to stay around, so I'm not going to bet against them.
While it may sound neat to say, ``go ahead, try to telnet to 10.200.120.4,'' it doesn't exactly work that way.
/; etc...) and had it output the mail to me (couldn't see the output from the CGI). I figured out the web server user had a shell and a writable home directory, and the machine had ssh (client and server installed). I generated a private key and had it mail me the public version of that key, then I added it to my authorized_keys and installed my public key in the web server's authorized_keys. Then I had the web server user ssh to my host with remote port forwarding back into the web server's 22. ssh -p 2222 localhost and I'm sitting in a shell on the web server (192.168.something).
Does this machine on 10.200.120.4 have the ability to make direct outbound connections? Assuming yes, does you realize that the only difference between an inbound connection and an outbound connection is who sent the first packet?
Many people tend to believe that the *only* security risk they have to worry about is inbound SYN packets, so they base their entire security policy on stopping bad inbound packets. The last two sites I broke into, I did so by tricking a machine to come to me. Just for humor, here are the two scenarios:
The first one was quite a while ago, and I did it at contract. A co-worker found a potential hole in a CGI, but nobody took it seriously. By sending the right data through the CGI, I found that I could make it execute arbitrary commands. First, I did some basic stuff (id; ls -lR
The next time I saw something like this, it was out in the wild. There was a web server that was running a CGI that *seemed* like it was probably just handing the input over to a command, so I gave it a shot. This time, the web server didn't have a usable home directory, so the ssh thing was out, but it did have X installed, so I fired up a VNC server, opened it to the world and opened an xterm up in it. Before too long, I had an entire X desktop running on some guy's web server. I sent the local admin an E-mail (through pine) letting him know what was wrong and recommending he fix it before someone meaner than I am comes along.
Anyway, point of the story. Having an unroutable IP address is good internet security as long as you keep it unrouted. Once you give the thing direct internet access, the unroutability of it becomes much less relevant.
I find it ridiculous that people believe it is their right to use company resources however they want. Basically, the more people can do with their computers on a public network, the higher the risk of something horrible happening because of this.
It's always a big conflict. They want employees to be really happy and feel like they can do whatever they want, but when something bad happens, they come and ask why and who. The discussions are always essentially, ``Is there any way we can keep people from doing bad things without preventing them from doing bad things?''
It's just stupid. They don't get TVs on their desks they can sit around and watch. They don't assume it's OK to spend a couple hours a day talking on the phone. They certainly don't think it's OK to bring one of their friends in and hang out all day.
There is a real risk here, and we've had to clean up after plenty of people who downloaded an app that broke their machines, leaked confidential information, harrassed people, etc... all using our resources. It's not like very many people actually need Internet access above local E-mail.
There are so few jobs where people even get internet access that it seems even more bizarre when people think of it as a fundamental job right.
I've not seen a comprehensive list of companies Microsoft has killed, but I was working with a guy from Quarterdeck who told me about how MS killed them.
Quarterdeck produced QEMM, which any old-school DOS users should remember as the best memory management system available at the time. MS wanted it, and offered to buy the company. The company did not want to sell. MS put in an a very large order for boxed copies of QEMM. Quarterdeck took out short-term loans to fill the order, and when they were ready to ship, MS cancelled. There goes a competitor.
I'm sure there are lots of stories like this we haven't heard.
I've been to a Wal-Mart twice since I moved away from Arkansas (it was my local grocery store). I can get the same products from other vendors, sometimes for more money, sometimes for less.
When was the last time someone told you that you *had* to purchase a telephone from Wal-Mart before you were allowed to talk to him?
I *just* finished my FreeBSD 4.5 upgrade on my database server last weekend. It was a big effort, as I've got multiple databases with tables ranging from a few to 7 million rows with referential integrity and average at least 1 insert every ten seconds every day.
Now I've gotta do it again!
This is plain and simple ignorance.
Every bit of code I write goes into CVS. My CVS repository is not open to the public, it's to help me track my own code. It gives me the freedom to make arbitrary experimental changes, toss them into a branch (or just throw them away and roll back my code), examine the difference between any two arbitrary dates for any two files, etc... It gives me an excellent history of development, per file, so I can know what I've done, when I did it, etc...
What it does *not* do, however, is encourage anyone to submit patches any more than they otherwise would. It's not voodoo. People don't hear that someone's using proper development tools and start spewing code generators at them.
If some guy allowed lots of people to dump code directly into his source tree, then, yeah, it's going to have as much crap as exists with the incoming patches nowadays, possible more. The solution isn't to avoid CVS, it's to not use it in really stupid ways. That's roughly the equivalent of saying, ``Linux development shouldn't happen under Linux because it's a multi-user OS and just anyone could be logged in changing the code at any given moment!'' Yep.
Now granted, that won't solve the immediate problem much like inflating your tires won't give you enough gas to start your car...but when you have two problems, why not solve them both?
Yes, it's true that it's not easy to revert bad stuff with CVS. It's not any easier without it. It's most certainly possible, though, especially if you were to tag every patch import.
Don't take development tool advice from someone who won't use the tools because they cause problems when you use them incorrectly.
I've been in enough situations where an application implemented by someone who didn't think through the design clearly enough had to be rewritten to meet new fundamental requirements, or, in some cases, to even work.
I don't believe that any actual programmers (i.e. the people who occasionally state they need to rewrite something) would make such a statement. As delicate as software is these days, it shouldn't be too much of a stretch to assume that some things cannot be repaired. Often, a prototype is thrown together as a proof-of-concept and needs to have its functionality designed to fit into a proper application, but instead, stuff just keeps getting glued onto the original prototype.
In a recent case, I had a very large application that was written in perl. It performed very badly and was all but impossible to extend. The business specification for the next version of the application included a lot of functionality we would not be able to add to the existing code base. We determined that we could, more quickly, create an entirely new code base in a new language that included all of the new functionality and all of the old functionality that was actually still used faster than we could've retrofitted the new requirements into the old code. We did.
It's ridiculous to think that the sum of work of a ton of junior programmers makes up an implementation that's worth retaining simply because it's there.
This would be a pretty big step backwards. The NetBSD startup stuff is far superior to SysV. They wanted to move to a similar model for a while, but anyone who's ever used SysV startup on a real system understands the problems.
Their current system allows you to drop files in a directory for startup that contain no special file names. They may list internally what service they provide, and what service they require and they will be sequenced properly. If you run two things that require network and don't provide anything that anything else requires, they'll get run after the network portion of the startup runs. There is no special shell scripting based on requested command (i.e. how many SysV startup scripts have you seen that implement ``start'' but not ``stop?''). Best thing is they're tiny, and they grow with the system. You define a couple variables and then do ``run_rc_command "$1"''
I think it's cool that people are trying different things, and I don't care as long as it's not wasting me money, but they'd probably be better off learning from a system rather than trying to assimilate the kernel while throwing away the other good stuff.
Your complaints about NetBSD are a result of your experience with FreeBSD? These are completely different *operating systems* (not kernels, full operating systems).
Windowmaker is not BSD. If you have a problem with Windowmaker, go complain to them.
Which parts of tuning require five years of experience and/or a CS degree? I switched from Linux to NetBSD after I'd been using computers for about two years altogether, and have always found it easier to work with. Why? Because it's a whole operating system. If stuff goes into the kernel, it's released with userland support, all at the same time.
NetBSD is, IMO, the cleanest system out there today. Everything works, and moving forward is easy. Doesn't come with bash? So what? I don't use bash, so I'm pretty happy to not see it. I do like the standard bourne shell it comes with for running my scripts. I do use tcsh, so it's typically one of the first things I install from pkgsrc on a new machine.
``But pkgsrc is hard! You have to build the stuff yourself,'' you say? A ``make package'' at the top level will create binary packages for the current platform for all packages your configuration suggests you're licensed for. Port maintainers typically do this and provide binary packages for most things people would want. In fact, when NetBSD releases ISOs, they release pre-built package ISOs for i386, just to make it a bit quicker (it certainly can't be any easier).
For the longest time, people would argue about how Linux isn't an operating system, just a kernel from which an operating system is made. Now people are going out there and taking a complete operating system, pulling a part out of it, and sticking it in the middle of what was normally a Linux distribution.
Linux is a Kernel without an operating system. NetBSD is a complete operating system where everything is designed to work together seamlessly.
What's next, DebiaNT?
I don't know about the rest of you guys, but I'm buying this video when it comes out.
baby# id /dev/null >! messages
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest), 37(resident)
baby# ls -lo messages
-rw-rw-r-- 1 root wheel sappnd 221149 Jan 7 17:16 messages
baby# rm -f messages
rm: messages: Operation not permitted
baby# cat
messages: Operation not permitted.
baby# logger "Test"
baby# tail -1 messages
Jan 10 12:40:25 baby username: Test
BSD's been doing that for quite a long time (that's an old OpenBSD/sparc machine).
The constitution does not guarantee the right to be heard by the general public.
I, at least, am not complaining about what the spam says, nor do I believe they shouldn't be allowed to advertise their products. My complaint is the amount of effort I have to go through in order to read my own E-mail.
Less than a week ago, I switched DSL providers from one that charged per usage to one that is always flat (i.e. spam no longer appears on my ISP bill). My very next day at work a CS rep was asking me what we can do to get some of the spam out of our customer service queues as our customer service representatives (many of whom are apparently Mormon) are spending more time (money) processing porn spam than customer requests.
Freedom of speech is not relevant here.
Just to attach to the thread of plugs...
I wrote mailfw the second time we had a problem like this. At my company, it's plucked attachments from 12,823 mails since June 2000.
It sounds fairly similar, examine every attachment recursively and check both the file extensions and the mime types against a lists, pull the bad content, and deliver the message with a note at the top that lists the things that were removed and why. 18 months without hearing about *that* problem.
I've got a friend who works at Danger and that just about describes their hiptop product.
Actually, it was pretty close. With contributions to my ``kittycode'' project, it's possible to pull up books at Amazon by ISBN, and other products by UPC if you've got a place that'll give you info by UPC. Look here.