A co-worker of mine is from Uganda. I pointed him to this question, and he wrote me with the following info. Apparently he is involved in this organization, helping to get Ugandans connected.
This gentleman could start by asking the Schoolnet Uganda project how to help this university if not he can use some other services I have listed below.
Vision: SchoolNet Uganda is a national network of professional educators and schools whose vision is to transform the Uganda educational system from an Industrial model (learning by assimilation) to a knowledge-based model to prepare the youth of Uganda to effectively enter a Global Economy based on Knowledge, Information and Technology.
Mission: SchoolNet Uganda's mission is to make graduates of Uganda's education system more globally competitive. SchoolNet Uganda supports Uganda educators and learners by providing pedagogical and technical expertise and advice, infrastructure and human resources, coordination, training and capacity building and developing SMART local and international partnerships in the areas of:
Internet Connectivity and Appropriate Technology
Content and Curriculum Development
Human Resources Development and Capacity Building
Community Responsibility and Development
Objective: SchoolNet Uganda's objective is to work in partnership with all Uganda educational institutions (public or private, primary, secondary or tertiary) to setup their ICT facilities and to develop technical and pedagogical capacity necessary to use ICT to enhance teaching and learning.
Current Membership: Presently there are 42 participating educational institutions geographically disbursed around the country.
Central Region (17): King's College Budo, Mengo SS, Gayaza HS, Namilyango College, Lubiri SS, Makerere College, Kitante HS, Kibuli SS, Nabisunsa Girls, Bombo SS, Ndejje SS, St. Mary's Kisubi, Mount. St. Mary's Namagunga, St. Henry's Kitovu, Maranatha PS, NCDC and Nkumba University. Eastern Region (11): Jinja SS, St. James, PMM Girls, Kiira College, Wanyange Girls SS, Busoga College Mwiri, Iganga Girls, Bukoyo SS, Mbale SS, Teso College, and Moroto High School. Northern Region (2): Lango College and Muni NTC. Western Region (4): Duhaga SS (Hoima), Ntare School, Bweranyange Girls and Kigezi High School. New Schools (8): Martyrs' SS Namugongo, Vienna College, Nsamba Girls, Rubaga Girls, Buloba HS, Kabojja SS, Mityana SS, and Trinity College Nabbingo
International Partners:
World Links Organization (Office Staff, Training activities, subsidy on VSAT connectivity costs).
Schools Online USA (Computers, Routers, Microwave wireless connectivitity equipment).
Bill and Melissa Gates Foundation (VSATs - earth satellite dishes for rural school's connectivity).
International Institute for Comunication and Development - IICD (Global Teenager Project & Adopt-a-School).
International Education and Resource Network - I*Earn (International School-to-School networking).
International Development Projects - IDP (Teacher Internships and Virtual Enterprise Projects).
International Institute for Capacity Building in Africa - UNESCO-IICBA (CD-based and Internet content creation and ICT Training).
Alpha Smart (Alpha Smart Keyboards).
Cisco Systems (Cisco Cache Engines).
Sun Microsystems (Sun Servers).
OBLIGATIONS OF THE PARTICIPATING SCHOOLS 1. Host the VSAT equipment. 2. Protect the VSAT antenna from human interference or otherwise by providing a cage for the equipment. 3. Keep the number of PCs connected to the Internet initially to no more than (10) not to disorganise the other schools sharing the same bandwidth. The bandwidth coming to the schools is 256 Kbs (shared) for the start. The schools can pay for more bandwidth. 4. Provide security and insurance for the equipment. 5. Pay
It takes years to learn how to program WELL in a complex language like C++.
Once you know how to program well, picking up a new language shouldn't take more than a few weeks, except in the most baroque cases.
I'd definitely consider C++ to be baroque. It's definitely complex and "feature-encrusted". I used to like C++, but the template rules are just too complex to be useful without using the language every day. I remember in the early 1990s, C++ fans used to berate Ada for having complex rules, but now C++ is much worse than Ada ever was. Look how long it took compiler vendors to get templates right. I still think a subset of C++ (without templates) is useful, but I'm becoming more of the opinion that "RAD" languages like Python are the way to go for application programming, with C/C++ for OS and core libraries.
You forgot "and you got to where you are today with a lot of hot air". I've also heard a variation with a helicopter pilot, where he figured out he was at Microsoft from the useless answer.
I don't exactly trust Gates' explanation that you referenced. Mainly because he's very innacurate when describing 8-bit vs. 16-bit vs. 32-bit. He says that 8-bit CPUs can address 64K. That is an incorrect statement. If a CPU has an address space of 64K, then it's more of an 8/16-bit CPU. The "bits" of a CPU can refer to several things -- register size, memory access chunks, and address space. The 68000 chip is 32/16/24. The 68008 is 32/8/24. The Pentium 4 is 32/64/40. The point is that the register size really has little bearing on the address space size. Note that he says that 32-bit CPUs have a 32-bit address space. (I believe the 386 was 32/16/32, and the 486 32/32/32.) Yet he's comparing that to 8-bit CPUs, which generally had 16-bit address space.
NT boot screen on hotel video system
on
Public BSOD Sightings?
·
· Score: 5, Interesting
I was staying at a nice brand new hotel, part of a popular chain. [Names omitted to protect the other guilty parties.] The in-room video system box had a noisy fan, so I unplugged it so I could sleep. The next day I plugged it in and saw the NT 4 boot screen on the TV. So I took a closer look at the box. It had an RJ-45 connector plugged into the wall.
So of course, I plugged my notebook into that wall jack to see what I could find. I got a DHCP address -- nice! So I looked at my default route and telnetted to it. A prompt. Some sort of IOS knock-off. Hmm, what would the password be? It took me about 3 tries -- it was the name of the company that sold the video system, which was written on the remote control. I didn't know enough about routers back then to know what to look for beyond that. I don't know if I might have been able to somehow connect to the Internet, or download their movies, or get into their reservation system. I really didn't want to get into that much trouble anyway. But just the fact that their router password was that obvious blew my mind.
Ah, point taken. The supposedly O(n) part of NetBSD-CURRENT has a factor of about 5. If the supposedly O(1) part is actually O(n), the maximum factor would be about 1, but it's hard to tell where it is between 0 and 1. So I can see your point. But how accurate/small a factor do you need before you can definitively say it's O(1) vs. O(n)? I think maybe this is a case where real-world graphs (and the multiplying factor) are more useful than Big-O notation.
I'm not quote following. The old and new algorithms are both graphed at the same scale, on the same graph. Or are you saying that the scale is too course to tell if the new algorithm is in fact mostly O(1) and may in fact be O(n) with a very small factor? Hmm, thinking about that, as the factor approaches 0, O(n) approaches O(1), doesn't it?
Technically yes, performance is still O(n). But if you were to describe the graphs to explain performance, you'd use the same language as the original author, plus note that the factor is much lower. BTW, I believe that it is accepted usage to use Big-O notation for typical as well as worst-case perfromance, but I could be wrong -- I haven't kept up with pure Comp Sci literature lately. Also note that the graphs pretty much cover about as high a load as is practical, so anything beyond the graphs is theoretical and has little effect on real life performance.
RTFA - specifically the graph of the mmap benchmark in question. Note that for the most part the red line goes straight across. But there are a few data points that follow a O(n) graph above that (what the author called a shadow). So the interpretation is that the typical case is O(1), but occasionally it has a worst-case performance of O(n). Plus, the factor of the O(n) case is much lower than the previous version.
Yes, there's a good site collecting all the information relevant to the SCO cases: SCOvsIBM. They've got an executive summary, analysis, a time-line, and links to almost every SCO article out there. The 2 other good sources are Groklaw and SCO's page, which has the actual legal documents pertaining to the case.
I've come to use a simple Parker Jotter (a basic retractable ball-point) because of my particular needs.
1. I write like a left-hander, dragging the side of my hand across the page as I write. So I need an ink that will not smear at all. Very few pens fit this criteria. 2. I often don't have a shirt pocket, but want to carry a pen. (Partly for reason 1.) The Parker Jotter is solid stainless steel and won't break when I sit on it. 3. If I carried an expensive pen around, I'd be likely to lose it eventually. The Parker Jotter costs less than $5, so I can buy several of them and not worry too much if I lose a few every year. 4. The Jotter fits my hand fairly well. It could stand to have a softer grip, but I don't usually write that much. (My gets pretty tired if I write a lot, mainly because I hold the pen wrong.)
I don't expect most people to have these same requirements, but I find that the Jotter is the best fit for my needs.
That's the one key. If your pimp ain't screwin' ya, he won't be embarassed to show you how much of a cut he's taking. You should also make sure you get to see the resume they're sending out to companies. I've had pimps rewrite my resume so poorly that I don't know how I ended up with the job. (They said I knew WAN and Seagate, which doesn't even make sense. The grammar was terrible, and it was for a tech writing job.) Also make sure that they get your permission to submit your resume to each company. Otherwise several firms may submit you for the same job, and the company won't want to get involved resolving the discrepancy.
You've got to realize that pimps are a necessary evil, and work with that knowledge. I.e. don't trust them, and take advantage of them, just as they take advantage of you. As you get to more senior positions, you'll be able to be selective in what pimps you work for, and have a better feel for the more honest ones.
Again, you're missing the point. SSH provides encryption, which is better than having no encryption. You've not suggested any solution that does encryption of data and authentication. These things do provide more security. SSL would of course be the other logical choice, probably around HTTP.
BTW, perhaps you missed the post suggesting turning off SSH's (inbound) tunneling ability. I would imagine that an SSH proxy would do the same. Of course netcat would get around that, but you could do similar things with HTTP tunnels.
You can tunnel (and back-tunnel) any protocol through any other. Which kind of leads to the original question: Yes, you do need to be looking inside the packets. But there will always be ways around/through. People have tunneled through ICMP pings, DNS lookups, and GotoMyPC even reverse tunnels a VNC/PCAnywhere type application through HTTP. Those are all payloads (layer 7). Inspecting at layer 3 or 4 (IP/TCP) doesn't help, and even application-layer proxies (actually closer to layer 6) aren't likely to detect most of these tunnels.
Saying that allowing SSH in eliminates all security is missing the forest for the trees. What would you suggest for file transfers, FTP? How about command sessions, Telnet? Security is not about making things bullet-proof. It's about mitigating exposure to risks. But I agree, if you're using SSH inbound, you should turn off port-forarding and shell access. It'd be best to put the system in your DMZ as well. And if possible, use an SSH application-layer proxy, although I'm not sure how feasible that is.
There's nothing wrong with a developer learning how computers work. In fact, I would encourage it. I've run into several programmers who didn't seem to know much about computers, and never could understand that. To be able to write a program, you need to know what the computer can do and how it does it. Understanding the CCNA materials will help you understand some basic networking concepts, so you'll be more prepared to write programs that involve networking. Which is sure to be a valuable skill.
The CCNA exam is more about networking fundamentals than running Cisco equipment. Unless you're already familiar with TCP/IP, switches, routers, the ISO model, LAN, and WAN, you'll probably get a lot out of the class. And nobody is going to expect you to build or run a network just because you have a CCNA -- it's just an entry level certification.
I'm a programmer by nature, but all my jobs in the past 10 years since college have been desktop support, system admin, and network admin. I've got a few programming certs on my resume, and it's either been irrelavent or an added bonus. I don't view the 2 jobs as all that different: either way, you're making computers do what people need them to do.
The weird thing about this mouse is that it had neither a mouse ball nor an optical sensor. Instead, it had 2 cam-like wheels that spun around (only in the horizontal plane) when you moved it. There's a picture on this page. There's a better picture here, but it still doesn't show you how the little buggers rotate. Unfortunately, I couldn't find a diagram. It's DEC part number VSXXX-AA.
No, the problem with HTML isn't that it's descriptive. The problem is that people are trying to make it do things that are completely contrary to what it was designed for. HTML was intentionally designed to leave the rendering implementation-defined. Here's a clue to the idiots that think that was a bad decision: try reading the same page on a cell phone PDA as on a 23-inch display. Either the PDA is going to be unreadable, or the 23-inch display will have 4-inch text.
To further see that the descriptive nature of HTML is in no way tied to the rendering being implementation-dependent, take a look at XSL-FO. It's basically an XML dialect (thus descriptive and similar to HTML) that does what you think HTML should do: it specifies exactly what a page should look like. Basically it's the same as PDF. Another example would be SVG, although I think you can do some procedural things in SVG. PostScript and PDF are somewhere between procedural and descriptive, much like Lisp.
As for GUI layout, again the automatic layout and desriptive code are completely separate. (Actually, GTK almost always uses automatic layout, even in procedural code.) Take a look at GLADE. It can either generate C code or you can use libglade to render the GUI at run-time according to the description in the XML file. They both work almost exactly the same, and the layout ends up being the same. Libglade offers some advantages in that you can allow the user (or a GUI designer) to change the layout after the program has been delivered. And it's a lot easier to use libglade in a wider variety of programming languages.
Besides, details are actually easier to specify in a descriptive file than in program code. You simply add an attribute and a value, instead of having to find the right function call and arguments to use.
You've convinced me in some ways, but not in others. I definitely buy your first point. But I have a problem with your position that compile-time allows for higher levels of abstraction. I'd counter that run-time has more information to work with, which allows for more choice in what level to work at.
I also don't think that code generators that write ugly incomprehensible code are a good thing. Ugly code generally runs poorly. If it's tedious code, then maybe that's another case, but it shoudn't be ugly. Even tedious code probably means that some refactoring would improve performance.
In the end, the code that gets run should end up the same, whether the opcodes are chosen at run-time or compile-time. So the question is which allows more flexibility, easier programming, and better performance?
As far as parsing, I think the trend is actually toward run-time, with XML. Basically, you have a choice between a parser library, with callback routines, or something like YACC or ANTLR with code fragments. (Would you use YACC to parse XML?) Personally, I think that the main reason we've stuck with YACC for so long is that that's the way we've always done things. That, plus (premature) optimization in thinking that compiled code is always faster.
Again, we're making the same compiler vs. interpreter trade-off arguments. So I suppose that if you've chosen C/C++ because of those trade-offs then compile-time code generation is probably the obvious choice. If you're using Perl or Python, then you're probably going to parse things at run-time. Java probably falls somewhere in the middle. Personally, I've been heading more toward preferring Python.
Ah, you're right -- I did miss the point of having more language tools to do the "conversion" at compile-time. I do realize that the choice of methods is situation-dependent. I just think that like most modern programming situations, programming time is more important than program efficiency. And compile-time code generation tends to take more programmer time. Really this is just the same old compiler vs. interpreter argument applied to descriptive code instead of procedural code. Today, it seems that the best answer is usually somewhere in between (Java, Perl, Python). Unfortunately, I still don't see descriptive "code" being given first-class status by most people.
I'm not buying your claim about run-time derivation and abstraction levels, since the target language is likely to be the same either way, even if the translation language is different. In other words, if your target language is Java, you're going to have to implement the resulting executable code in Java either way. I suppose there may be a top-down versus bottom-up distinction in the abstraction development process between the two methods though.
BTW, is there a well-used term to distinguish run-time derivation from code generation?
OK, I'm clearly of the opinion that a lot of "code" should be descriptive instead of procedural. It just doesn't make sense to explain the steps to create a GUI, when you can simply describe how it should look and act, and have the computer figure out how to best implement it. (Of course the actions bound to events would generally have procedural code behind them.)
But I'm not very clear on the advantages of code generation versus descriptive code. One example I like to use is glade versus libglade. The advantage of being able to convert a descriptive file at run-time seems to outweigh the benefits of doing it at compile time. You can change the GUI without having to compile at all. Which allows non-programmers to more easily make changes. (And since it's descriptive, non-programmers are often better at doing the work.)
Besides efficiency, you've given the only reasonable explanation that I've seen for code generation versus dynamically doing the work from the description. I.e. compile-time error checking and info in the object code. But I don't find that to be all that helpful either. If the descriptive file has errors, it's not going to work either way. And you're going to have to do your error checking on the descriptive code the same way, whether you're doing it at compile time or run-time. Compile-time checking of the generated code really doesn't give you much either, except to debug the code generator.
That's an excellent observation! I've often thought about it in terms of influencing behavior. But I also believe that it's not the governement's business how I think or behave, as long as it doesn't harm others. So I've always felt a little uncomfortable with the two ideas being internally inconsistent. But by phrasing it your way, it makes a lot more sense -- you try to influence behavior only insomuch as it effects (harms) society as a whole, and only enough to offset the harm.
Of course, determining how much social cost a given behavior has is probably impossible, and will still lead to disagreements.
Slashdot Mirror
Thanks, that's a pretty darn good answer.
According to the link I provided, no -- bonobos are not chimps. They are commonly called pygmy chimps, but it says that is an incorrect label.
A co-worker of mine is from Uganda. I pointed him to this question, and he wrote me with the following info. Apparently he is involved in this organization, helping to get Ugandans connected.
http://www.schoolnetuganda.sc.ug/
====
This gentleman could start by asking the Schoolnet Uganda project how to help this university if not he can use some other services I have listed below.
Vision:
SchoolNet Uganda is a national network of professional educators and schools whose vision is to transform the Uganda educational system from an Industrial model (learning by assimilation) to a knowledge-based model to prepare the youth of Uganda to effectively enter a Global Economy based on Knowledge, Information and Technology.
Mission:
SchoolNet Uganda's mission is to make graduates of Uganda's education system more globally competitive. SchoolNet Uganda supports Uganda educators and learners by providing pedagogical and technical expertise and advice, infrastructure and human resources, coordination, training and capacity building and developing SMART local and international partnerships in the areas of:
Internet Connectivity and Appropriate Technology
Content and Curriculum Development
Human Resources Development and Capacity Building
Community Responsibility and Development
Objective:
SchoolNet Uganda's objective is to work in partnership with all Uganda educational institutions (public or private, primary, secondary or tertiary) to setup their ICT facilities and to develop technical and pedagogical capacity necessary to use ICT to enhance teaching and learning.
Current Membership:
Presently there are 42 participating educational institutions geographically disbursed around the country.
Central Region (17): King's College Budo, Mengo SS, Gayaza HS, Namilyango College, Lubiri SS, Makerere College, Kitante HS, Kibuli SS, Nabisunsa Girls, Bombo SS, Ndejje SS, St. Mary's Kisubi, Mount. St. Mary's Namagunga, St. Henry's Kitovu, Maranatha PS, NCDC and Nkumba University.
Eastern Region (11): Jinja SS, St. James, PMM Girls, Kiira College, Wanyange Girls SS, Busoga College Mwiri, Iganga Girls, Bukoyo SS, Mbale SS, Teso College, and Moroto High School.
Northern Region (2): Lango College and Muni NTC.
Western Region (4): Duhaga SS (Hoima), Ntare School, Bweranyange Girls and Kigezi High School.
New Schools (8): Martyrs' SS Namugongo, Vienna College, Nsamba Girls, Rubaga Girls, Buloba HS, Kabojja SS, Mityana SS, and Trinity College Nabbingo
International Partners:
World Links Organization (Office Staff, Training activities, subsidy on VSAT connectivity costs).
Schools Online USA (Computers, Routers, Microwave wireless connectivitity equipment).
Bill and Melissa Gates Foundation (VSATs - earth satellite dishes for rural school's connectivity).
International Institute for Comunication and Development - IICD (Global Teenager Project & Adopt-a-School).
International Education and Resource Network - I*Earn (International School-to-School networking).
International Development Projects - IDP (Teacher Internships and Virtual Enterprise Projects).
International Institute for Capacity Building in Africa - UNESCO-IICBA (CD-based and Internet content creation and ICT Training).
Alpha Smart (Alpha Smart Keyboards).
Cisco Systems (Cisco Cache Engines).
Sun Microsystems (Sun Servers).
OBLIGATIONS OF THE PARTICIPATING SCHOOLS
1. Host the VSAT equipment.
2. Protect the VSAT antenna from human interference or otherwise by providing a cage for the equipment.
3. Keep the number of PCs connected to the Internet initially to no more than (10) not to disorganise the other schools sharing the same bandwidth. The bandwidth coming to the schools is 256 Kbs (shared) for the start. The schools can pay for more bandwidth.
4. Provide security and insurance for the equipment.
5. Pay
I'd definitely consider C++ to be baroque. It's definitely complex and "feature-encrusted". I used to like C++, but the template rules are just too complex to be useful without using the language every day. I remember in the early 1990s, C++ fans used to berate Ada for having complex rules, but now C++ is much worse than Ada ever was. Look how long it took compiler vendors to get templates right. I still think a subset of C++ (without templates) is useful, but I'm becoming more of the opinion that "RAD" languages like Python are the way to go for application programming, with C/C++ for OS and core libraries.
I thought it was well-established that bonobos are the species most closely related to humans.
You forgot "and you got to where you are today with a lot of hot air". I've also heard a variation with a helicopter pilot, where he figured out he was at Microsoft from the useless answer.
I don't exactly trust Gates' explanation that you referenced. Mainly because he's very innacurate when describing 8-bit vs. 16-bit vs. 32-bit. He says that 8-bit CPUs can address 64K. That is an incorrect statement. If a CPU has an address space of 64K, then it's more of an 8/16-bit CPU. The "bits" of a CPU can refer to several things -- register size, memory access chunks, and address space. The 68000 chip is 32/16/24. The 68008 is 32/8/24. The Pentium 4 is 32/64/40. The point is that the register size really has little bearing on the address space size. Note that he says that 32-bit CPUs have a 32-bit address space. (I believe the 386 was 32/16/32, and the 486 32/32/32.) Yet he's comparing that to 8-bit CPUs, which generally had 16-bit address space.
I was staying at a nice brand new hotel, part of a popular chain. [Names omitted to protect the other guilty parties.] The in-room video system box had a noisy fan, so I unplugged it so I could sleep. The next day I plugged it in and saw the NT 4 boot screen on the TV. So I took a closer look at the box. It had an RJ-45 connector plugged into the wall.
So of course, I plugged my notebook into that wall jack to see what I could find. I got a DHCP address -- nice! So I looked at my default route and telnetted to it. A prompt. Some sort of IOS knock-off. Hmm, what would the password be? It took me about 3 tries -- it was the name of the company that sold the video system, which was written on the remote control. I didn't know enough about routers back then to know what to look for beyond that. I don't know if I might have been able to somehow connect to the Internet, or download their movies, or get into their reservation system. I really didn't want to get into that much trouble anyway. But just the fact that their router password was that obvious blew my mind.
Ah, point taken. The supposedly O(n) part of NetBSD-CURRENT has a factor of about 5. If the supposedly O(1) part is actually O(n), the maximum factor would be about 1, but it's hard to tell where it is between 0 and 1. So I can see your point. But how accurate/small a factor do you need before you can definitively say it's O(1) vs. O(n)? I think maybe this is a case where real-world graphs (and the multiplying factor) are more useful than Big-O notation.
I'm not quote following. The old and new algorithms are both graphed at the same scale, on the same graph. Or are you saying that the scale is too course to tell if the new algorithm is in fact mostly O(1) and may in fact be O(n) with a very small factor? Hmm, thinking about that, as the factor approaches 0, O(n) approaches O(1), doesn't it?
Technically yes, performance is still O(n). But if you were to describe the graphs to explain performance, you'd use the same language as the original author, plus note that the factor is much lower. BTW, I believe that it is accepted usage to use Big-O notation for typical as well as worst-case perfromance, but I could be wrong -- I haven't kept up with pure Comp Sci literature lately. Also note that the graphs pretty much cover about as high a load as is practical, so anything beyond the graphs is theoretical and has little effect on real life performance.
RTFA - specifically the graph of the mmap benchmark in question. Note that for the most part the red line goes straight across. But there are a few data points that follow a O(n) graph above that (what the author called a shadow). So the interpretation is that the typical case is O(1), but occasionally it has a worst-case performance of O(n). Plus, the factor of the O(n) case is much lower than the previous version.
Yes, there's a good site collecting all the information relevant to the SCO cases: SCOvsIBM. They've got an executive summary, analysis, a time-line, and links to almost every SCO article out there. The 2 other good sources are Groklaw and SCO's page, which has the actual legal documents pertaining to the case.
I've come to use a simple Parker Jotter (a basic retractable ball-point) because of my particular needs.
1. I write like a left-hander, dragging the side of my hand across the page as I write. So I need an ink that will not smear at all. Very few pens fit this criteria.
2. I often don't have a shirt pocket, but want to carry a pen. (Partly for reason 1.) The Parker Jotter is solid stainless steel and won't break when I sit on it.
3. If I carried an expensive pen around, I'd be likely to lose it eventually. The Parker Jotter costs less than $5, so I can buy several of them and not worry too much if I lose a few every year.
4. The Jotter fits my hand fairly well. It could stand to have a softer grip, but I don't usually write that much. (My gets pretty tired if I write a lot, mainly because I hold the pen wrong.)
I don't expect most people to have these same requirements, but I find that the Jotter is the best fit for my needs.
Hah! I wasn't expecting that!
For one thing, I thought I had called you as soon as I found out. I didn't know that you found out from the web site. What're you up to now?
Craig (his "boss" at the time the company went bust)
That's the one key. If your pimp ain't screwin' ya, he won't be embarassed to show you how much of a cut he's taking. You should also make sure you get to see the resume they're sending out to companies. I've had pimps rewrite my resume so poorly that I don't know how I ended up with the job. (They said I knew WAN and Seagate, which doesn't even make sense. The grammar was terrible, and it was for a tech writing job.) Also make sure that they get your permission to submit your resume to each company. Otherwise several firms may submit you for the same job, and the company won't want to get involved resolving the discrepancy.
You've got to realize that pimps are a necessary evil, and work with that knowledge. I.e. don't trust them, and take advantage of them, just as they take advantage of you. As you get to more senior positions, you'll be able to be selective in what pimps you work for, and have a better feel for the more honest ones.
Again, you're missing the point. SSH provides encryption, which is better than having no encryption. You've not suggested any solution that does encryption of data and authentication. These things do provide more security. SSL would of course be the other logical choice, probably around HTTP.
BTW, perhaps you missed the post suggesting turning off SSH's (inbound) tunneling ability. I would imagine that an SSH proxy would do the same. Of course netcat would get around that, but you could do similar things with HTTP tunnels.
You can tunnel (and back-tunnel) any protocol through any other. Which kind of leads to the original question: Yes, you do need to be looking inside the packets. But there will always be ways around/through. People have tunneled through ICMP pings, DNS lookups, and GotoMyPC even reverse tunnels a VNC/PCAnywhere type application through HTTP. Those are all payloads (layer 7). Inspecting at layer 3 or 4 (IP/TCP) doesn't help, and even application-layer proxies (actually closer to layer 6) aren't likely to detect most of these tunnels.
Saying that allowing SSH in eliminates all security is missing the forest for the trees. What would you suggest for file transfers, FTP? How about command sessions, Telnet? Security is not about making things bullet-proof. It's about mitigating exposure to risks. But I agree, if you're using SSH inbound, you should turn off port-forarding and shell access. It'd be best to put the system in your DMZ as well. And if possible, use an SSH application-layer proxy, although I'm not sure how feasible that is.
There's nothing wrong with a developer learning how computers work. In fact, I would encourage it. I've run into several programmers who didn't seem to know much about computers, and never could understand that. To be able to write a program, you need to know what the computer can do and how it does it. Understanding the CCNA materials will help you understand some basic networking concepts, so you'll be more prepared to write programs that involve networking. Which is sure to be a valuable skill.
The CCNA exam is more about networking fundamentals than running Cisco equipment. Unless you're already familiar with TCP/IP, switches, routers, the ISO model, LAN, and WAN, you'll probably get a lot out of the class. And nobody is going to expect you to build or run a network just because you have a CCNA -- it's just an entry level certification.
I'm a programmer by nature, but all my jobs in the past 10 years since college have been desktop support, system admin, and network admin. I've got a few programming certs on my resume, and it's either been irrelavent or an added bonus. I don't view the 2 jobs as all that different: either way, you're making computers do what people need them to do.
The weird thing about this mouse is that it had neither a mouse ball nor an optical sensor. Instead, it had 2 cam-like wheels that spun around (only in the horizontal plane) when you moved it. There's a picture on this page. There's a better picture here, but it still doesn't show you how the little buggers rotate. Unfortunately, I couldn't find a diagram. It's DEC part number VSXXX-AA.
No, the problem with HTML isn't that it's descriptive. The problem is that people are trying to make it do things that are completely contrary to what it was designed for. HTML was intentionally designed to leave the rendering implementation-defined. Here's a clue to the idiots that think that was a bad decision: try reading the same page on a cell phone PDA as on a 23-inch display. Either the PDA is going to be unreadable, or the 23-inch display will have 4-inch text.
To further see that the descriptive nature of HTML is in no way tied to the rendering being implementation-dependent, take a look at XSL-FO. It's basically an XML dialect (thus descriptive and similar to HTML) that does what you think HTML should do: it specifies exactly what a page should look like. Basically it's the same as PDF. Another example would be SVG, although I think you can do some procedural things in SVG. PostScript and PDF are somewhere between procedural and descriptive, much like Lisp.
As for GUI layout, again the automatic layout and desriptive code are completely separate. (Actually, GTK almost always uses automatic layout, even in procedural code.) Take a look at GLADE. It can either generate C code or you can use libglade to render the GUI at run-time according to the description in the XML file. They both work almost exactly the same, and the layout ends up being the same. Libglade offers some advantages in that you can allow the user (or a GUI designer) to change the layout after the program has been delivered. And it's a lot easier to use libglade in a wider variety of programming languages.
Besides, details are actually easier to specify in a descriptive file than in program code. You simply add an attribute and a value, instead of having to find the right function call and arguments to use.
You've convinced me in some ways, but not in others. I definitely buy your first point. But I have a problem with your position that compile-time allows for higher levels of abstraction. I'd counter that run-time has more information to work with, which allows for more choice in what level to work at.
I also don't think that code generators that write ugly incomprehensible code are a good thing. Ugly code generally runs poorly. If it's tedious code, then maybe that's another case, but it shoudn't be ugly. Even tedious code probably means that some refactoring would improve performance.
In the end, the code that gets run should end up the same, whether the opcodes are chosen at run-time or compile-time. So the question is which allows more flexibility, easier programming, and better performance?
As far as parsing, I think the trend is actually toward run-time, with XML. Basically, you have a choice between a parser library, with callback routines, or something like YACC or ANTLR with code fragments. (Would you use YACC to parse XML?) Personally, I think that the main reason we've stuck with YACC for so long is that that's the way we've always done things. That, plus (premature) optimization in thinking that compiled code is always faster.
Again, we're making the same compiler vs. interpreter trade-off arguments. So I suppose that if you've chosen C/C++ because of those trade-offs then compile-time code generation is probably the obvious choice. If you're using Perl or Python, then you're probably going to parse things at run-time. Java probably falls somewhere in the middle. Personally, I've been heading more toward preferring Python.
Ah, you're right -- I did miss the point of having more language tools to do the "conversion" at compile-time. I do realize that the choice of methods is situation-dependent. I just think that like most modern programming situations, programming time is more important than program efficiency. And compile-time code generation tends to take more programmer time. Really this is just the same old compiler vs. interpreter argument applied to descriptive code instead of procedural code. Today, it seems that the best answer is usually somewhere in between (Java, Perl, Python). Unfortunately, I still don't see descriptive "code" being given first-class status by most people.
I'm not buying your claim about run-time derivation and abstraction levels, since the target language is likely to be the same either way, even if the translation language is different. In other words, if your target language is Java, you're going to have to implement the resulting executable code in Java either way. I suppose there may be a top-down versus bottom-up distinction in the abstraction development process between the two methods though.
BTW, is there a well-used term to distinguish run-time derivation from code generation?
But I'm not very clear on the advantages of code generation versus descriptive code. One example I like to use is glade versus libglade. The advantage of being able to convert a descriptive file at run-time seems to outweigh the benefits of doing it at compile time. You can change the GUI without having to compile at all. Which allows non-programmers to more easily make changes. (And since it's descriptive, non-programmers are often better at doing the work.)
Besides efficiency, you've given the only reasonable explanation that I've seen for code generation versus dynamically doing the work from the description. I.e. compile-time error checking and info in the object code. But I don't find that to be all that helpful either. If the descriptive file has errors, it's not going to work either way. And you're going to have to do your error checking on the descriptive code the same way, whether you're doing it at compile time or run-time. Compile-time checking of the generated code really doesn't give you much either, except to debug the code generator.
That's an excellent observation! I've often thought about it in terms of influencing behavior. But I also believe that it's not the governement's business how I think or behave, as long as it doesn't harm others. So I've always felt a little uncomfortable with the two ideas being internally inconsistent. But by phrasing it your way, it makes a lot more sense -- you try to influence behavior only insomuch as it effects (harms) society as a whole, and only enough to offset the harm.
Of course, determining how much social cost a given behavior has is probably impossible, and will still lead to disagreements.