Yes it is popular, and that's part of the reason so many of the linux faithful hate it. Despite whatever many linux users claim about how it's the true best choice and everybody should use it, a good number of them like it specifically because it gives them computer hipster status. Ubuntu's popularity is a bad thing to them. if "the masses" use something, it -must- be bad, since the masses are idiots.
I love Xubuntu in spite of losing all my geek cred by using anything related to Ubuntu. I still use *BSD for servers and routers, so it's not like I'm a sellout, but I'd rather have a slightly unstable laptop/desktop than go to the effort of using a higher-cred distro that is similarly-unstable. Huge bonus points for being realistically-usable by people without special training.
I, for one, welcome a future where MS Windows is just an option among many.
There are still vast ranges of unused addresses that have not been monetized, so there's no incentive to change. The cost of conversion is higher than the cost of addresses, therefore we will keep using them and developing software that doesn't support IPv6 until costs escalate.
Beyond this, how many of your ISPs offer native IPv6? This will be a prerequisite to widespread consumer adoption.
Not entirely. The touch interface on an iPad is distinctly superior to keyboard/trackpad/touchscreen/mouse interfaces on laptops. iOS is one of very few operating systems that makes a touchscreen a viable input method.
Instead of a standard laptop or dedicated tablet (or the utter crap they sell as convertible tablets), I'd rather tote a reasonably-rugged convertible laptop/tablet with the same form factor as an ultrabook and an excellent touch screen interface. The only existing manufacturer that could do this well is a company that would never consider the potential of incorporating a physical keyboard into a tablet (nor allowing proper peripherals). Oh well.
The variable that the successful project had is what makes projects succeed without regard to methodology: A team of skilled, intelligent, and disciplined participants.
In my 16 years in the industry I've only been on a couple teams like this. The results were exceptional, but it was an anomaly in a sea of mediocrity and failure (at least when I've worked within a team; lone-developer projects tend to have extremely high functional completion rates but long lead times).
Excellent developers will simply leave a poorly-managed company and over time the poorest-quality developers will concentrate within these organizations. Due to various factors these groups outnumber excellent teams by at least ten-to-one, and probably closer to twenty-to-one. This roughly matches the development project success rates I recall hearing from the grissled old developers that became professors... Methodology cannot correct for poor management and developers, simple as that.
On one-person projects and even multi-person projects where no more than one or two developers are working on the code simultaenously (provided there is no other bug tracking system), I also do this. Bug resolution is defined by the bug being removed from the text file and the log entry on the commit.
I'm also not generally fond of bug tracking systems due to the additional effort involved and the bad effects they can have on an organization.
Nobody said you had to switch the 'packets' at line speed. We're talking about a fairly dumb tube for most of the distance, but in some regions a tag on the 'packet' indicates that it needs to be switched off the trunk, so you drop it to a manageable speed (ex: 60 mph) and transfer it to another tube. If it's going all the way you simply keep it at velocity. Los Angeles to New York would be 41 minutes, but Chicago or Atlanta might be 35, even though the actual distance of the trips might be shorter.
The funny thing is that it would still cost more to get to Chicago than New York from Los Angeles, even though the distance is shorter, because your switching would require a delay in traffic to New York.
I still think this is a great public works project idea.
Actually, that's probably an optimal route. If you group California's flights (not just LA) that go to the northeast corridore, this would easily be economically viable. The problem is that the startup cost and long lead time before it'd be functional would make the actual construction costs far higher.
But if you could get people from Los Angeles to New York (or just above anywhere in the northeast corridore) in 41 minutes, rather than 375 minutes, everyone within 120-180 minutes of either end point by some form of transport to somewhere within 120-180 minutes of the other end, you could easily replace 95% of cross-country flights within the US.
With effective 'packet' switching, you could run a trunk down the center of the country and split off to Chicago or Atlanta somewhere in the middle. This could revolutionize meatspace networking.
Large-scale deforestation (and perhaps more importantly, large-scale destruction of grassland) preceded modern use of fossil fuels by tens of thousands of years, with deserts and extinctions resulting from some of it.
I'd readily argue that high nitrogen fertilizers are more damaging than all the CO2 and CH4 pumped into the environment.
Maybe I'm oldschool, but I seem to remember these configurations being really common in production environments when I was a young programmer:
Java-based website: INTERNET [firewall forwarding ports 80 and/or 443] WEB SERVER(s) [firewall forwarding port 8080] APPLICATION SERVER(s) [firewall forwarding ports for users to access production RDBMS] DATABASE SERVER(s)
Light PHP/Perl/Python/etc script-based website: INTERNET [firewall forwarding ports 80 and/or 443] WEB SERVER(s) [firewall forwarding ports for users to access production RDBMS] DATABASE SERVER(s)
Hybrid script-based website: INTERNET [firewall forwarding ports 80 and/or 443] STATIC WEB SERVER(s)/CACHING FRONTEND WEB SERVER(s) [may have firewall for added security (same ports as above firewall), but not required] DYNAMIC WEB SERVER(s) [firewall forwarding ports for users to access production RDBMS] DATABASE SERVER(s)
Many also had layers of load balancers that were grouped with the web servers, or sometimes with firewalls between the two.
In the development environment you can have the same configuration, with each layer accessible as necessary. Average internal users access at most the network the web servers are on. Developers will have access to all but the database (which is still behind the innermost firewall). DBAs will have access to the network beyond the innermost firewall. The cracker might get into the front end web servers/caching servers, from which they could crack the outermost firewall to allow easier access, but to get through the next requires exploiting another/different bug to get into these servers before they can crack and reconfigure that firewall. Then a quality DBA won't allow any direct access to your users tables from any user that can access the database through the firewall (which will be compromised if the next layer above is compromised), restricting it exclusively to stored procedures that insert, validate, or delete user records (You cannot simply dump the users table(s). A DBA worth his salary should have wrapped everything even slightly sensitive in stored procedures and disallowed direct access to the tables to the users, in fact.) Even the internal company network should only access the database though the innermost firewall (and that network should have no access to internet-facing production servers or the application servers).
As mentioned above, production data should never be used for development database servers (except when specific data is isolated that results in errors, then that alone should be moved into development for debugging).
There's no excuse for the theft of production data to anything short of a rouge DBA and/or physical security failures.
Being a 'merkin, I thought it was all in my head, but apparently I was correct. The only total dickheads I encountered were Audi drivers, particularly the small and mid-sized ones. They reminded me of 3-series and 5-series BMW drivers in the US...
Slashdot Mirror
I never said you shouldn't, I was simply answering the obvious before it was asked.
Yeah, and it's the state religion in a number of other countries. The headline seems to indicate that Indonesia is the only country that observes it.
Before you ask, yes, I call Lent a "holiday", too.
Isn't Ramadan a Muslim holiday? How is it "the country's holy month"?
Yes it is popular, and that's part of the reason so many of the linux faithful hate it. Despite whatever many linux users claim about how it's the true best choice and everybody should use it, a good number of them like it specifically because it gives them computer hipster status. Ubuntu's popularity is a bad thing to them. if "the masses" use something, it -must- be bad, since the masses are idiots.
I love Xubuntu in spite of losing all my geek cred by using anything related to Ubuntu. I still use *BSD for servers and routers, so it's not like I'm a sellout, but I'd rather have a slightly unstable laptop/desktop than go to the effort of using a higher-cred distro that is similarly-unstable. Huge bonus points for being realistically-usable by people without special training.
I, for one, welcome a future where MS Windows is just an option among many.
It reminds me of the early-mid 90s where basically every connected computer had a public IP address. It was glorious.
There are still vast ranges of unused addresses that have not been monetized, so there's no incentive to change. The cost of conversion is higher than the cost of addresses, therefore we will keep using them and developing software that doesn't support IPv6 until costs escalate.
Beyond this, how many of your ISPs offer native IPv6? This will be a prerequisite to widespread consumer adoption.
I meant "on-screen keyboard" in the second sentence, not a physical keyboard.
Not entirely. The touch interface on an iPad is distinctly superior to keyboard/trackpad/touchscreen/mouse interfaces on laptops. iOS is one of very few operating systems that makes a touchscreen a viable input method.
Instead of a standard laptop or dedicated tablet (or the utter crap they sell as convertible tablets), I'd rather tote a reasonably-rugged convertible laptop/tablet with the same form factor as an ultrabook and an excellent touch screen interface. The only existing manufacturer that could do this well is a company that would never consider the potential of incorporating a physical keyboard into a tablet (nor allowing proper peripherals). Oh well.
...and input directly from my mind.
The variable that the successful project had is what makes projects succeed without regard to methodology: A team of skilled, intelligent, and disciplined participants.
In my 16 years in the industry I've only been on a couple teams like this. The results were exceptional, but it was an anomaly in a sea of mediocrity and failure (at least when I've worked within a team; lone-developer projects tend to have extremely high functional completion rates but long lead times).
Excellent developers will simply leave a poorly-managed company and over time the poorest-quality developers will concentrate within these organizations. Due to various factors these groups outnumber excellent teams by at least ten-to-one, and probably closer to twenty-to-one. This roughly matches the development project success rates I recall hearing from the grissled old developers that became professors... Methodology cannot correct for poor management and developers, simple as that.
On one-person projects and even multi-person projects where no more than one or two developers are working on the code simultaenously (provided there is no other bug tracking system), I also do this. Bug resolution is defined by the bug being removed from the text file and the log entry on the commit.
I'm also not generally fond of bug tracking systems due to the additional effort involved and the bad effects they can have on an organization.
On a brand new machine about three months ago (that was 1000 miles away when it happened). Don't ask me why it lost the settings.
The customer definitely wasn't too happy with the song and dance to bring the machine up when it needed a reboot (headless server)...
Nobody said you had to switch the 'packets' at line speed. We're talking about a fairly dumb tube for most of the distance, but in some regions a tag on the 'packet' indicates that it needs to be switched off the trunk, so you drop it to a manageable speed (ex: 60 mph) and transfer it to another tube. If it's going all the way you simply keep it at velocity. Los Angeles to New York would be 41 minutes, but Chicago or Atlanta might be 35, even though the actual distance of the trips might be shorter.
The funny thing is that it would still cost more to get to Chicago than New York from Los Angeles, even though the distance is shorter, because your switching would require a delay in traffic to New York.
I still think this is a great public works project idea.
Actually, that's probably an optimal route. If you group California's flights (not just LA) that go to the northeast corridore, this would easily be economically viable. The problem is that the startup cost and long lead time before it'd be functional would make the actual construction costs far higher.
But if you could get people from Los Angeles to New York (or just above anywhere in the northeast corridore) in 41 minutes, rather than 375 minutes, everyone within 120-180 minutes of either end point by some form of transport to somewhere within 120-180 minutes of the other end, you could easily replace 95% of cross-country flights within the US.
With effective 'packet' switching, you could run a trunk down the center of the country and split off to Chicago or Atlanta somewhere in the middle. This could revolutionize meatspace networking.
Large-scale deforestation (and perhaps more importantly, large-scale destruction of grassland) preceded modern use of fossil fuels by tens of thousands of years, with deserts and extinctions resulting from some of it.
I'd readily argue that high nitrogen fertilizers are more damaging than all the CO2 and CH4 pumped into the environment.
Many also had layers of load balancers that were grouped with the web servers, or sometimes with firewalls between the two.
In the development environment you can have the same configuration, with each layer accessible as necessary. Average internal users access at most the network the web servers are on. Developers will have access to all but the database (which is still behind the innermost firewall). DBAs will have access to the network beyond the innermost firewall. The cracker might get into the front end web servers/caching servers, from which they could crack the outermost firewall to allow easier access, but to get through the next requires exploiting another/different bug to get into these servers before they can crack and reconfigure that firewall. Then a quality DBA won't allow any direct access to your users tables from any user that can access the database through the firewall (which will be compromised if the next layer above is compromised), restricting it exclusively to stored procedures that insert, validate, or delete user records (You cannot simply dump the users table(s). A DBA worth his salary should have wrapped everything even slightly sensitive in stored procedures and disallowed direct access to the tables to the users, in fact.) Even the internal company network should only access the database though the innermost firewall (and that network should have no access to internet-facing production servers or the application servers).
As mentioned above, production data should never be used for development database servers (except when specific data is isolated that results in errors, then that alone should be moved into development for debugging).
There's no excuse for the theft of production data to anything short of a rouge DBA and/or physical security failures.
Being a 'merkin, I thought it was all in my head, but apparently I was correct. The only total dickheads I encountered were Audi drivers, particularly the small and mid-sized ones. They reminded me of 3-series and 5-series BMW drivers in the US...
You beat me to it! I was going to point out that "rainbow trout" don't migrate out to sea.