They have problems relating to me. Clearly, their inability to discuss low-level network protocol details makes them ill-equiped for life in the real world. They must have some sort of mild disorder.
I guess he's writing it for me then, because I like the current batch a whole lot more than the older ones I've read. Can't please everyone.
I had assumed that the increased level of technical detail was an evolutionary step to keep pace with state of the art in infosec. You're seeing articles about deep buffer overflow stuff because, frankly, that's what's being used out there.
And the loopback section isn't all "you idiot!". There is equal measure of "are you coming on to me?".
It's pretty inconvienient to sniff an analog modem connection directly.
Here's how you might go about it:
Never used Dreamcast myself, but I presume you can program in a phone number that it dials to get ot the net?
If for some reason you can't pick an arbitrary number, take it to work and make friends with your PBX admin. They can get it to drop on a particular extension no matter what number it dials.
Have your own PPP server answer the call. If it's a *nix machine, you can probably sniff the PPP interface directly.
If you can't sniff the PPP, or your PPP server is a Windows box or some such, just pull it off the Ethernet after it's routed.
I've e-mailed Router a couple times about this, and the reason he cites every time is not enough quality articles.
Folks may have noticed that rather than put out poor quality, Route will write articles himself. If he has to do this, it will take him much longer.
I have no doubt in my mind that if Route got 20 articles with the same level of quality as Greg's article in a week's time, we'd have issue 56 next week.
I get impatient too, but I'd rather maintain the technical level.
For modem dial-up, it's pretty simple to use RFC1918 addresses and IP Masquerade. Last time I used it, it didn't support a lot of things (ICMP, typical reverse-connection stuff like DCC send). You lose some performance running over 7-bit ascii transports.
Pro:
There's some pretty good NAT code out there now. It outght to be possible to borrow some of that to fix some protocols that don't work. It's nice sometimes nice to pic up you connection from a machine you're not directly dialed into. As mentioned in other replies, one can combine this with SSH to make a handy VPN. It appears to be less platform specific, so is easier to port.
I'm glad to hear that it's good for a lot of the things I find important. I will most likely check it out.
I'm not surprised that it doesn't have as many add-ons as perl. I don't really know of a language that does... at least, not as well organized as the perl ones so that you would know.
As for the simplicity question.. My point is that if you take an overly complex set of functions, you can't simply make them simpler with a set of glue code, not without losing functionality. For example, Windows GUI programming is nasty. MS released a set of classes to help, which makes it less nasty. It also lessens the ability to futz with the details. It's messy because of callbacks, type conversions, complex data structures, etc...
Python wouldn't simply that significantly. It's not Pythons' fault.
I also don't think number 3 was one of the intended goals. That leaves #1, #2, and whetever options I didn't think of. If #1 or #2 are close to the mark, then Python sounds like it could be a reasonable choice.
As with anything you try to accomplish, you have to know what your goal is. Is it:
1.Teaching students a programming language to get them used to programming constructs, with an eye towards them being able to pick up other programming languages? 2.Teaching students a language that they can write useful programs in from scratch? 3.Teaching students programming so that they can get jobs as commercial programmers?
I should start out by saying that I know nothing about Python. I've done C, C++, Scheme, Fortran, BASIC, Pascal, Modula2, perl, sh, and probably others I've forgotten about.
If the goal is #1, then any of the simpler, syntactically consistent languages are a good choice. If Python was designed with beginners in mind, it may be useful for that.
If the goal is #2, then there is a potential problem. Any language, no matter how simple, start to get ugly when you have to interact with the rest of the world. By that, I mean the Windows GUI, socket code, X, real-world file formats, etc... For me, the things that makes a language interesting are the add-ons available, i.e. libs, free code, examples, ability to act as glue, do system calls, etc.. Python might be great for that, I don't know. But the point is, if that is the goal, you can probably kiss a lot of the simplicity goodbye. Further, if writing glue-type programs is the primary goal, then perl or C might be better, because of the vast number of add-ons.
If the goal is #3, well then they should probably just learn C. If you think the existing code base of C is a problem, then yes this feeds it. It is a market reality, though. Note that doing #1 as a way to get to #3 might be a very valid path.
My feelings? If the kid loves programming, it doesn't matter what language they start with. They'll pick their own language(s) as needed. Do some studies, and see what language tends to spark an interest in kids.
If you're just trying to get them a marketable skill, teach 'em C, and give them the certificate that says they can program. It will be as useful as the other certifications out there.
Folks who want to ask questions about how to write for O'Reilly should probably read the excellent resource that they have already provided:
http://www.oreilly.com/oreilly/author/intro.html
Most of these questions have already been answered. I'd hate to waste a question that will probably have the answer: "read the FAQ"
Re:You don't want USB 2.0 for pro stuff
on
Is firewire dying?
·
· Score: 1
All of the PCs I've seen so far with USB (and, of course it's the current slower version) have two ports. From what I've read, those two ports have an independent path back to the rest of the system. So would a potential fix be (on a USB 2.0 system) to plug the fast devices into one port, and the slow ones into another?
>Last time I checked, his books already covered IPv6, so it won't be a problem. He had even thought about that!
I'm aware of that.. but there's a big difference in writing a book based on a proposed standard, and writing about a real-world set of implementations. The latter is something he excelled at.
Also, I don't mean to sound insensitive. I do feel sympathy for his family. However, I only know the guy through his books, and having looked at his web page. Never had any kind of personal contact with him. Hence, my main feeling of loss is for the works he produces.
Now, for those of you still spouting the rhetoric about apple's prices, I'd like to remind you that the new G4, classified as a supercomputer by the government, thus a weapon (and as of yet, unexportable to other countries), is available for a starting price of 1599. If anyone out there tells me that is too much money to pay for a computer with a top of the line processor, Modem, Ethernet, Firewire, USB, 128-bit video card, and more, plus the wonderful support of Apple (rated very highly every year) and the ease of use and increase in productivity it brings, well, then they really don't know a good deal when they see one.
Pentium IIs aren't exportable either (to the 7 countries, mind you. Same as the G4.) Non-exportability does not a supercomputer make.
You can get an Intel-based system with similar hardware for about $800, so yes, $1599 is way too much, Especially if you're planning to run Linux on it anyway. Knock off a hundred or so if you really don't need the Firewire. Granted, the G4 looks like it will have better CPU performance than the $800 PC, but if you're really worried about that, spend another $200 and add a second CPU.
I used to support Macs. Apple support sucks. Their software is no easier for support people to support than any other. People who say that haven't spend an entire day troubleshooting incompatible inits, rebooting in between each combination. Why should I have to blow away the PRAM periodically for an unknown reason? How is that better than Windows?
Slashdot Mirror
I was hoping for the source code to their IP stack when I saw the title!
This doesn't do me much good... my chip fab is at the cleaners.
Go into the information security field.
They have problems relating to me. Clearly, their inability to discuss low-level network protocol details makes them ill-equiped for life in the real world. They must have some sort of mild disorder.
I guess he's writing it for me then, because I like the current batch a whole lot more than the older ones I've read. Can't please everyone.
I had assumed that the increased level of technical detail was an evolutionary step to keep pace with state of the art in infosec. You're seeing articles about deep buffer overflow stuff because, frankly, that's what's being used out there.
And the loopback section isn't all "you idiot!". There is equal measure of "are you coming on to me?".
It's pretty inconvienient to sniff an analog modem connection directly.
Here's how you might go about it:
Never used Dreamcast myself, but I presume you can program in a phone number that it dials to get ot the net?
If for some reason you can't pick an arbitrary number, take it to work and make friends with your PBX admin. They can get it to drop on a particular extension no matter what number it dials.
Have your own PPP server answer the call. If it's a *nix machine, you can probably sniff the PPP interface directly.
If you can't sniff the PPP, or your PPP server is a Windows box or some such, just pull it off the Ethernet after it's routed.
The funding model is very simple:
He wants articles.
I've e-mailed Router a couple times about this, and the reason he cites every time is not enough quality articles.
Folks may have noticed that rather than put out poor quality, Route will write articles himself. If he has to do this, it will take him much longer.
I have no doubt in my mind that if Route got 20 articles with the same level of quality as Greg's article in a week's time, we'd have issue 56 next week.
I get impatient too, but I'd rather maintain the technical level.
I already had WAY too much stuff to do today, and now I have to spend an hour or two reading Phrack! Thanks alot.
BTW, the FTP link was a bad choice. It's about dead, but you can pull it via HTTP pretty easily.
Phrack 55
So, NT on Alpha gets dumped, and they come crawling to the Linux community for a market.
Well, I think it's going to take more than your standard commercial license to get us interested.
Let's see some GPL, Mister!
Con:
For modem dial-up, it's pretty simple to use RFC1918 addresses and IP Masquerade. Last time I used it, it didn't support a lot of things (ICMP, typical reverse-connection stuff like DCC send). You lose some performance running over 7-bit ascii transports.
Pro:
There's some pretty good NAT code out there now. It outght to be possible to borrow some of that to fix some protocols that don't work. It's nice sometimes nice to pic up you connection from a machine you're not directly dialed into. As mentioned in other replies, one can combine this with SSH to make a handy VPN. It appears to be less platform specific, so is easier to port.
I hit escape before the form was posted! You bastard!
(Don't mind me... just having a discussion with the CGI script. Clearly, it's in the wrong...)
Does this mean I get dinosaurs or not?
Does this mean I get dinosuars or not?
The force is strong in this sheep.
Not even Master Yoda has a reading that high.
"Would the G4 run special calculations on the Velocity engine and 'transmit' on RF that way?"
Yup, they communicate over hyperspace.
This is accomplished by modulating the fequency at which the machines divide by 0.
Make it so that anonymous cowards don't have a way to turn off the comments from other anonymous cowards.
"Mommy! Grandma bluescreened!"
I'm glad to hear that it's good for a lot of the things I find important. I will most likely check it out.
I'm not surprised that it doesn't have as many add-ons as perl. I don't really know of a language that does... at least, not as well organized as the perl ones so that you would know.
As for the simplicity question.. My point is that if you take an overly complex set of functions, you can't simply make them simpler with a set of glue code, not without losing functionality. For example, Windows GUI programming is nasty. MS released a set of classes to help, which makes it less nasty. It also lessens the ability to futz with the details. It's messy because of callbacks, type conversions, complex data structures, etc...
Python wouldn't simply that significantly. It's not Pythons' fault.
I also don't think number 3 was one of the intended goals. That leaves #1, #2, and whetever options I didn't think of. If #1 or #2 are close to the mark, then Python sounds like it could be a reasonable choice.
It's not
As with anything you try to accomplish, you have to know what your goal is. Is it:
1.Teaching students a programming language to get them used to programming constructs, with an eye towards them being able to pick up other programming languages?
2.Teaching students a language that they can write useful programs in from scratch?
3.Teaching students programming so that they can get jobs as commercial programmers?
I should start out by saying that I know nothing about Python. I've done C, C++, Scheme, Fortran, BASIC, Pascal, Modula2, perl, sh, and probably others I've forgotten about.
If the goal is #1, then any of the simpler, syntactically consistent languages are a good choice. If Python was designed with beginners in mind, it may be useful for that.
If the goal is #2, then there is a potential problem. Any language, no matter how simple, start to get ugly when you have to interact with the rest of the world. By that, I mean the Windows GUI, socket code, X, real-world file formats, etc... For me, the things that makes a language interesting are the add-ons available, i.e. libs, free code, examples, ability to act as glue, do system calls, etc.. Python might be great for that, I don't know. But the point is, if that is the goal, you can probably kiss a lot of the simplicity goodbye. Further, if writing glue-type programs is the primary goal, then perl or C might be better, because of the vast number of add-ons.
If the goal is #3, well then they should probably just learn C. If you think the existing code base of C is a problem, then yes this feeds it. It is a market reality, though. Note that doing #1 as a way to get to #3 might be a very valid path.
My feelings? If the kid loves programming, it doesn't matter what language they start with. They'll pick their own language(s) as needed. Do some studies, and see what language tends to spark an interest in kids.
If you're just trying to get them a marketable skill, teach 'em C, and give them the certificate that says they can program. It will be as useful as the other certifications out there.
Folks who want to ask questions about how to write for O'Reilly should probably read the excellent resource that they have already provided:
l
http://www.oreilly.com/oreilly/author/intro.htm
Most of these questions have already been answered. I'd hate to waste a question that will probably have the answer: "read the FAQ"
All of the PCs I've seen so far with USB (and, of course it's the current slower version) have two ports. From what I've read, those two ports have an independent path back to the rest of the system. So would a potential fix be (on a USB 2.0 system) to plug the fast devices into one port, and the slow ones into another?
>Last time I checked, his books already covered IPv6, so it won't be a problem. He had even thought about that!
I'm aware of that.. but there's a big difference in writing a book based on a proposed standard, and writing about a real-world set of implementations. The latter is something he excelled at.
Also, I don't mean to sound insensitive. I do feel sympathy for his family. However, I only know the guy through his books, and having looked at his web page. Never had any kind of personal contact with him. Hence, my main feeling of loss is for the works he produces.
I've enjoyed his books.
I may be most sad for selfish reasons.. I was looking forward to more. Who's going to update his books when/if IPV6 gets rolled out?
The feds classify it as a supercomputer, but they're the only ones.
Of course, in the age of beowulf clusters, the idea of supercomputers is obsolete.
(And clusters have been possible for as long as computers have been around.)
Yup. It makes as much sense as the crypto export laws.
Now, for those of you still spouting the rhetoric about apple's prices, I'd like to remind you that the new G4, classified as a supercomputer by the government, thus a weapon (and as of yet, unexportable to other countries), is available for a starting price of 1599. If anyone out there tells me that is too much money to pay for a computer with a top of the line processor, Modem, Ethernet, Firewire, USB, 128-bit video card, and more, plus the wonderful support of Apple (rated very highly every year) and the ease of use and increase in productivity it brings, well, then they really don't know a good deal when they see one.
Pentium IIs aren't exportable either (to the 7 countries, mind you. Same as the G4.) Non-exportability does not a supercomputer make.
You can get an Intel-based system with similar hardware for about $800, so yes, $1599 is way too
much, Especially if you're planning to run Linux on it anyway. Knock off a hundred or so if you really don't need the Firewire. Granted, the G4 looks like it will have better CPU performance than the $800 PC, but if you're really worried about that, spend another $200 and add a second CPU.
I used to support Macs. Apple support sucks. Their software is no easier for support people to support than any other. People who say that haven't spend an entire day troubleshooting incompatible inits, rebooting in between each combination. Why should I have to blow away the PRAM periodically for an unknown reason? How is that better than Windows?
>>3a. IRIX is unstable/insecure/unreliable. I
>>don't think these sorts of comments are >>relevant.
>Then your an idiot!
A.K.A. "Not a sysadmin"
Ryan