But the only ones _I_ would trust would be in my web of trust, and since the people I deal with don't sign keys without personal verification, I can trust the ones I have signed, and one hop away.
Non-AJAX, non-javascript, pure CGI way: Click "Reply" in given thread. Wait for the "reply" form for given thread to load. Type your answer. Click "preview". Wait for preview to load. Click "send". Wait for the whole discussion page, 100 posts, plus your answer to load.
Right click, select open in new tab, continue reading the next comment while the tab opens. Then reply. You don't _have_ to stop. And for most web fora, the context switch cost from comment to reply to comment is small and can be ignored.
Of course, in good software development, a problem is only solved once. If you need to do it twice, make it a function (or object method or whatever). If you are repeating the solution, you are doing something wrong.
Software isn't about making repeatable solutions, it is about making templates. That is the art in TAOCP.
He said developers, not programmers (or even engineers).
What management _wants_ is engineers. What exists in the real world is programmers, and coders/developers. What management does not want (generally) is programmers (hard to replace). They get developers (who can be replaced).
The one true religion stuff is Judaism, Christianity and Islam.
South Asian and East Asian religions are not as focussed on being the one true religion, as much as following a path. They even agree that the path is different for different people, and you should follow your own path.
You are not damned for following a different religion. Even the concept of "eternal" hell is non-existent.
(Which has absolutely nothing to do with my being an atheist and agreeing that religion is madness).
Excessive change requirements means the business analysis was flawed and incomplete to begin with, blaming the programmer is a self denial in such cases
I am not speaking about excessive change. Business environments change. Some projects take time to implement (think ERP). What happens when business requirements change during the implementation period? It may be something as simple as new reporting requirements (think SOX) leading to a lot of changes for access tracking.
Saying that this should have been in place is fine, but legal requirements can force changes in implementation schedules.
The shuttle design has been constant for quite sometime. If newer shuttles were being designed every few years, and the requirements changing from supporting a few people to say, supporting a couple of thousand people in orbit for a decade or so... Or even requiring that food be grown in hydroponic farms onboard and that the entire environment be controlled so that the people stay physically and mentally healthy.
The shuttle software works in a relatively stable operating environment with known parameters. Most commercial software works in varying operating enviroments, with different parameters per user. There is a lot more complexity in a PC than the space shuttle, and lesser budget.
Interestingly, _everyone_ I know who works at one of those process driven shops is in the 9/10 category. The best people either resufe to work for those shops, or walk out within a year because they can't stand the process.
It isn't the process that makes people successful, as much as the people who make the process a success.
And perhaps you should give a suggestion on how to deal with changing requirements as well, when those changes do involve considerable rethinking of the application?
The problem is when non Asian countries want to call people in Asia. You know, not being able to get to your helpdesk, or outsourced IT department because you are not running IPv6 can be... painful.
Well, the problem for quite a bit of Asia is that the content is not local yet. Also, IPv6 support wasn't quite all there in previously installed equipment. Now the situation is changing, and rollovers are happening, albeit slowly. IPv4 is still there for compatibility with the US Internet deployment.
Cellular devices (mainly from China) are the big pressing fricking issue here and for the most part cell phones do NOT need real public IP space.
Chinanet users are double NATted. Those are end users behind two layers of NAT. Broadband in China has started rolling out. Indian broadband is taking off. VoIP has been deregulated to some extent in India, and that is THE fastest growing cellphone market right now.
When you have half a billion users requiring IP address space, IPv4 isn't very likely to be able to scale up. The most realistic predictions I heard a couple of weeks ago were between 2009 to 2011 for IANA to run out of IPv4 space. We have between three to five years to upgrade, which is a reasonable amount of time to actually do it.
If you think that NAT is just needed for cellphones, think again. There are corporates which are running out of private IP space for internal use (an entire/8, a/12 and a/16), and they are getting public IP space for _internal_ use. Perhaps US ISPs should start NATing their users.
Slashdot Mirror
But the only ones _I_ would trust would be in my web of trust, and since the people I deal with don't sign keys without personal verification, I can trust the ones I have signed, and one hop away.
Non-AJAX, non-javascript, pure CGI way: Click "Reply" in given thread. Wait for the "reply" form for given thread to load. Type your answer. Click "preview". Wait for preview to load. Click "send". Wait for the whole discussion page, 100 posts, plus your answer to load.
Right click, select open in new tab, continue reading the next comment while the tab opens. Then reply. You don't _have_ to stop. And for most web fora, the context switch cost from comment to reply to comment is small and can be ignored.
About 500 INR
We could just use usenet, email, IRC, and the Google cache, for those times when we do need to use the web. Oh, and P2P. And ....
The advertising Internet would get the flashy content and advertising.
Would that be so bad?
Errr, no. It takes _light_ 4.3 years to cover that distance. At near light speeds, you are going to exceed that time.
Think about it.
Alternatives
Of course, in good software development, a problem is only solved once. If you need to do it twice, make it a function (or object method or whatever). If you are repeating the solution, you are doing something wrong.
Software isn't about making repeatable solutions, it is about making templates. That is the art in TAOCP.
He said developers, not programmers (or even engineers).
What management _wants_ is engineers. What exists in the real world is programmers, and coders/developers. What management does not want (generally) is programmers (hard to replace). They get developers (who can be replaced).
The one true religion stuff is Judaism, Christianity and Islam.
South Asian and East Asian religions are not as focussed on being the one true religion, as much as following a path. They even agree that the path is different for different people, and you should follow your own path.
You are not damned for following a different religion. Even the concept of "eternal" hell is non-existent.
(Which has absolutely nothing to do with my being an atheist and agreeing that religion is madness).
Thats no moon
No, that one is ambulanca chaseris. entrepreneurius-maximus is the link between monkeys and humans.
/me drives down to London, hops into the tube and dodges the helicopter.
No one ever threatens an independent nuclear power.
ImageMagick + your friendly file manager?
Dude! That is the only unbroken chair to leave that office. Put it up on Ebay! Quick!
Excessive change requirements means the business analysis was flawed and incomplete to begin with, blaming the programmer is a self denial in such cases
I am not speaking about excessive change. Business environments change. Some projects take time to implement (think ERP). What happens when business requirements change during the implementation period? It may be something as simple as new reporting requirements (think SOX) leading to a lot of changes for access tracking.
Saying that this should have been in place is fine, but legal requirements can force changes in implementation schedules.
The shuttle design has been constant for quite sometime. If newer shuttles were being designed every few years, and the requirements changing from supporting a few people to say, supporting a couple of thousand people in orbit for a decade or so... Or even requiring that food be grown in hydroponic farms onboard and that the entire environment be controlled so that the people stay physically and mentally healthy.
The shuttle software works in a relatively stable operating environment with known parameters. Most commercial software works in varying operating enviroments, with different parameters per user. There is a lot more complexity in a PC than the space shuttle, and lesser budget.
Interestingly, _everyone_ I know who works at one of those process driven shops is in the 9/10 category. The best people either resufe to work for those shops, or walk out within a year because they can't stand the process.
It isn't the process that makes people successful, as much as the people who make the process a success.
And perhaps you should give a suggestion on how to deal with changing requirements as well, when those changes do involve considerable rethinking of the application?
Actually true. I promised not to let out details, but their network design is _nice_. *Drool*. Professionally built backbones rock.
SELinux?
The problem is when non Asian countries want to call people in Asia. You know, not being able to get to your helpdesk, or outsourced IT department because you are not running IPv6 can be ... painful.
Well, the problem for quite a bit of Asia is that the content is not local yet. Also, IPv6 support wasn't quite all there in previously installed equipment. Now the situation is changing, and rollovers are happening, albeit slowly. IPv4 is still there for compatibility with the US Internet deployment.
Nah. The problem with the healthcare often is that you can't _call_ the doctor/hospital in time, or get to a specialist.
A major problem for the economic growth of people is lack of communications, rather than lack of food and water.
The problem is input and output devices. Small keyboards suck. And large keyboards are not exactly portability friendly.
Cellular devices (mainly from China) are the big pressing fricking issue here and for the most part cell phones do NOT need real public IP space.
/8, a /12 and a /16), and they are getting public IP space for _internal_ use. Perhaps US ISPs should start NATing their users.
Chinanet users are double NATted. Those are end users behind two layers of NAT. Broadband in China has started rolling out. Indian broadband is taking off. VoIP has been deregulated to some extent in India, and that is THE fastest growing cellphone market right now.
When you have half a billion users requiring IP address space, IPv4 isn't very likely to be able to scale up. The most realistic predictions I heard a couple of weeks ago were between 2009 to 2011 for IANA to run out of IPv4 space. We have between three to five years to upgrade, which is a reasonable amount of time to actually do it.
If you think that NAT is just needed for cellphones, think again. There are corporates which are running out of private IP space for internal use (an entire
man ifconfig
Enjoy
Unix platform, or desktop Unix platform?
And is that in the US, or globally?
Out here, Macs are rare while Linux is far more common on the desktop,