Go look at what's required in NYC installations and tell me it's not way overkill. The fiber will not have any metal in it. Buried cable usually will have a small metal tracer in it to make it easy to locate. Within an apartment building, there's no need for that (esp. given the expensive of that stuff.) The ONT itself is a low-voltage device. Requiring it's power brick be grounded, as well as the coax TV output, and the POTS telephone outputs... is stupid. It's not required anywhere else, nor have millions of people been fried by the lack of uber-grounding.
This is also a red-herring. Go ask Verizon how "easy" it is/was to get fiber everywhere in NYC. Red tape out the wazzo from the city itself. And then an independent fight with every major property owner. And then the city has to put it's nose in there again. (damned extensive grounding requirements for a f'ing glass fiber connectivity device.)
For anything I ever plan to watch more than once, streaming is inefficient. It's easy enough to do it the way Tivo (amazon, blockbuster, etc.), and DTV/DISH video-on-demand is handled... download to the DVR, in sequence, from the beginning; you can begin watching it immediately, but that depends on the various networks being able to keep up -- in my experience, the CDN is usually too slow, 'tho I know it doesn't have to be. (*cough*netflix*cough*)
Not true, 'tho they like confessions more than evidence. Juries are made up of mostly idiots, after all.
If all you have is a confession and no evidence, evidence to the contrary, that confession is almost useless. Get a good lawyer, and that "confession" won't even exist.
By that definition, there are zero "web developers" on Earth. I don't want to count the number of over-paid "developers" who's answer is use X toolkit, while completely ignoring the size of the thing or the fact that they're using 0.2% of it, and the size of the datasets they load (and go out of their way to never allow to be cached) are too huge, and almost entirely static. I've dealt with this crap for many, many, many years; so I default to "idiot" whenever web programming is on the table.
(There may be good web devs out there, but I've never met one or seen their code.)
The root issue is people are stupid and lazy. If your 250k of JS actually does things, that's one thing. When you include (an uncompressed) version of JQuery to use one tiny function (that you don't JQuery to actually do), or worse don't use any part of it, you're wasting everyone's time and bandwidth.
Every time I research how to do something in a browser, every. single. fucking. time. The top 90 out of 100 answers is to load some enormous bloated framework widget toolkit and kitchen sink replicator. for what has, in every case so far, boiled down to 1-2k of formatted, human readable JS. Apparently, I'm the only motherf***er in the universe that cares if his web page is 3k vs 300k, in 1 file vs. dozens.
You'd have to ask them; I guess they wanted in on the whole wardriving craze -- over a decade late... The FCC only covers cell sites in the USA. (nor does it say which towers are actually *on*)
What f'ing "guesswork"? They know where the tower is, and draw a circle around it. Done. No engineer; just a database (that anyone can build from FCC data, btw) and simple program (I did it with a bash shell script.) Using Google Earth elevation data would make it a little more accurate, but that's a lot more programming.
Actually, quite a lot of people do, but like everything on the internet, it depends on the site and specifics of the group of people it attracts. Game portals will have a very hit adblock rate, while the my little pony forum users... not so much.
They ALL have low CPM. And the more obnoxious and intrusive the ad, the more you're pushing people to ad blockers. (or simply abandoning your site) With the ever increasing greed from ISPs in the form of bandwidth limits and heavy overage fees, **I** don't want to be paying the per-byte costs of completely USELESS content. Go use the internet over dialup for just an hour and tell me how much you like all the bull**** ads, or the overabundance of enormous javascript libraries.
The only reason it "takes longer" is because you spend FAR less time excessively speeding. The drag on a car increases exponentially the faster you go. Simply staying between 60 and 70mph will do a lot for fuel economy; hanging out in the trailing edge of a semi's vortex will do even more amazing things. (I once did 60mpg in a Lexus HS along I-20 in SC; and then 30 in the other direction:-) No truck, and I was movin')
Incorrect. Watch some windtunnel tests. The vortex is behind the vehicle, not beside it.
A better word for this is "slipstream". You get close enough to have no air to push through. If your car has radar cruise control, following close enough to make a huge difference isn't too dangerous. (obviously on a highway where people aren't very unpredictable. and you're far better off following semi's.)
No, it's more of a "how many times do I let you fool me" kind of thing. Google has learned Java is not something that can NOT be trusted. As a result, chrome will refuse to load some versions entirely, others nags about constantly, and even the current latest versions require user confirmation before running the known-to-be-buggy-as-hell system.
a) they're symbolic links. b) if you cannot count (S01 happens before S02, etc.), then you have no place fucking with a *NIX system.
The claim that SMF does away with all those nasty shell scripts is an absolute and complete LIE. It just has them in different places. After installing Solaris 10 for the first time, I dug deep into the "init replacement"; the shell scripts were still there -- just not in/etc/init.d -- retooled to use the SMF DB instead of simple, everybody-know-about-them everybody-knows-how-to-use-them config files.
The issue with serialized vs. parallel boot is the lie of efficiency. The push for parallel is the task that sits idle waiting for an outside event. The thing that camp fails to understand is the possible (and often very real) I/O contention from too many processes reading and writing at startup, which can (and does) make boot actually take longer. It's a fine line they don't know how to walk.
And yet, it's still a decade behind. Low clocked RISC processors are just too damned slow for many modern applications. Sure, it can run many threads in parallel, but the answer from each one will be 5x (or more) slower than their cheap, commodity Xeon and Opteron competition.
(@ 20k+ for a SPARC T4 server, I can buy a dozen (or more) x64 servers)
IMO (shared with many of my peers), Solaris 10 is when it died. And it's entirely because of SMF. It has too much of a Windows Stink(tm) to it... want to change a service configuration, run the SMF equiv of "regedit". The init system has a database -- it replicates ("rolling backup") at startup -- instead of clearly defined, easy to understand, and trivial to edit configuration files. While SMF does add one or two notable features -- automatic dependency trees, parallel startup, error handling... Most of it has already been done with the existing (shell scripted) init framework. And parallel is one of those things that looks good on paper, and sounds good in the conference room, but when actually done just makes a mess. (one any windows users should be very familiar with... the complete inability to use a system for several minutes post-boot because 87 applications are thrashing the disk all trying to start at once. Yes, it's annoying having to sit and watch the machine do nothing for a minute waiting for sendmail's dns lookup to timeout to finish booting, but the start-almost-everything-at-the-same-time alternative is *worse*)
You've completely missed the part about UNLESS YOU BUILD IT YOURSELF... windows is more or less a "built yourself" installation as there aren't any "system" pythons -- they're going to put stuff where the porter wants it, which is self-contained in 99.9% of the versions I've heard of. The distro provided versions (esp. Redhat) intentionally have common search location(s) that can be a pain to override.
If you're a python developer, then you'll very likely have numerous local builds without such issues. For common end users, no one is going to go to all the trouble necessary to side-step the system python, or build their own self-contained version. (an app provider might, but I don't know of *any* that do -- outside windows, and many windows python apps simply include a "step 1: install activestate python x.y.z")
Said by someone who clearly has not tried to run multiple versions of python on the same system. Unless you built the non-system versions specifically to NEVER look outside your own locked down, version dependent install, it's going to touch system-wide, non-versioned areas, and in the process either itself fail, or touch something causing the system python to fail. And when your system package manager depends on he system python, you've created a lot of work for yourself.
This is entirely why over 90% of cases, the python in use is the one that shipped with the distro. (since windows doesn't ship with python, there are far less non-versioned overlap.)
Building it yourself can also be a bigger pain than upgrading the OS. Say you need py3 on an old redhat 9 (or centos 4) platform. Good luck, as it'll require building/upgrading hundreds of libraries and additional dependencies. (this is why we couldn't upgrade trac without rebuilding the server.)
Indeed. That's why you don't cut the car off after driving around at WOT. (Also, the ECU keeps various cooling pumps running after the engine is cut off.) As I understand it, this is how VW still does it. It's lasted 13 years and counting. (it's nearing 70k miles now, so it should fly apart like clockwork. most likely on track at VIR; followed by the insane bill for spilling oil all over their precious new track.)
It'll still have an oil pan, and several quarts/litres of oil. The rings are only one of many places where things touch. Also, that oil is one of the things cooling the piston. (and in my car, cooling the turbo)
Slashdot Mirror
(capital eye) INTERSTATE HIGHWAY number 20
Go look at what's required in NYC installations and tell me it's not way overkill. The fiber will not have any metal in it. Buried cable usually will have a small metal tracer in it to make it easy to locate. Within an apartment building, there's no need for that (esp. given the expensive of that stuff.) The ONT itself is a low-voltage device. Requiring it's power brick be grounded, as well as the coax TV output, and the POTS telephone outputs... is stupid. It's not required anywhere else, nor have millions of people been fried by the lack of uber-grounding.
This is also a red-herring. Go ask Verizon how "easy" it is/was to get fiber everywhere in NYC. Red tape out the wazzo from the city itself. And then an independent fight with every major property owner. And then the city has to put it's nose in there again. (damned extensive grounding requirements for a f'ing glass fiber connectivity device.)
Live there? Not so much. Be an ISP there? You BET! High density makes for cheap, efficient, networking.
Put another way: would you rather provide networking to every street light along I-20, or every apartment in a single, one block, 12-story building?
For anything I ever plan to watch more than once, streaming is inefficient. It's easy enough to do it the way Tivo (amazon, blockbuster, etc.), and DTV/DISH video-on-demand is handled... download to the DVR, in sequence, from the beginning; you can begin watching it immediately, but that depends on the various networks being able to keep up -- in my experience, the CDN is usually too slow, 'tho I know it doesn't have to be. (*cough*netflix*cough*)
Click one of the orange dots. It'll give you just about as much not-information. "It's down", and "It's back" is all Google(tm) has said about it.
Have you ever met Network Solution? Screwing their customers is ALL THEY DO.
Not true, 'tho they like confessions more than evidence. Juries are made up of mostly idiots, after all.
If all you have is a confession and no evidence, evidence to the contrary, that confession is almost useless. Get a good lawyer, and that "confession" won't even exist.
By that definition, there are zero "web developers" on Earth. I don't want to count the number of over-paid "developers" who's answer is use X toolkit, while completely ignoring the size of the thing or the fact that they're using 0.2% of it, and the size of the datasets they load (and go out of their way to never allow to be cached) are too huge, and almost entirely static. I've dealt with this crap for many, many, many years; so I default to "idiot" whenever web programming is on the table.
(There may be good web devs out there, but I've never met one or seen their code.)
The root issue is people are stupid and lazy. If your 250k of JS actually does things, that's one thing. When you include (an uncompressed) version of JQuery to use one tiny function (that you don't JQuery to actually do), or worse don't use any part of it, you're wasting everyone's time and bandwidth.
Every time I research how to do something in a browser, every. single. fucking. time. The top 90 out of 100 answers is to load some enormous bloated framework widget toolkit and kitchen sink replicator. for what has, in every case so far, boiled down to 1-2k of formatted, human readable JS. Apparently, I'm the only motherf***er in the universe that cares if his web page is 3k vs 300k, in 1 file vs. dozens.
You'd have to ask them; I guess they wanted in on the whole wardriving craze -- over a decade late... The FCC only covers cell sites in the USA. (nor does it say which towers are actually *on*)
What f'ing "guesswork"? They know where the tower is, and draw a circle around it. Done. No engineer; just a database (that anyone can build from FCC data, btw) and simple program (I did it with a bash shell script.) Using Google Earth elevation data would make it a little more accurate, but that's a lot more programming.
Actually, quite a lot of people do, but like everything on the internet, it depends on the site and specifics of the group of people it attracts. Game portals will have a very hit adblock rate, while the my little pony forum users... not so much.
They ALL have low CPM. And the more obnoxious and intrusive the ad, the more you're pushing people to ad blockers. (or simply abandoning your site) With the ever increasing greed from ISPs in the form of bandwidth limits and heavy overage fees, **I** don't want to be paying the per-byte costs of completely USELESS content. Go use the internet over dialup for just an hour and tell me how much you like all the bull**** ads, or the overabundance of enormous javascript libraries.
INCREASE! Increased MPG == less fuel burned.
The only reason it "takes longer" is because you spend FAR less time excessively speeding. The drag on a car increases exponentially the faster you go. Simply staying between 60 and 70mph will do a lot for fuel economy; hanging out in the trailing edge of a semi's vortex will do even more amazing things. (I once did 60mpg in a Lexus HS along I-20 in SC; and then 30 in the other direction :-) No truck, and I was movin')
Incorrect. Watch some windtunnel tests. The vortex is behind the vehicle, not beside it.
A better word for this is "slipstream". You get close enough to have no air to push through. If your car has radar cruise control, following close enough to make a huge difference isn't too dangerous. (obviously on a highway where people aren't very unpredictable. and you're far better off following semi's.)
No, it's more of a "how many times do I let you fool me" kind of thing. Google has learned Java is not something that can NOT be trusted. As a result, chrome will refuse to load some versions entirely, others nags about constantly, and even the current latest versions require user confirmation before running the known-to-be-buggy-as-hell system.
While I find it annoying, I do agree with them.
a) they're symbolic links. b) if you cannot count (S01 happens before S02, etc.), then you have no place fucking with a *NIX system.
The claim that SMF does away with all those nasty shell scripts is an absolute and complete LIE. It just has them in different places. After installing Solaris 10 for the first time, I dug deep into the "init replacement"; the shell scripts were still there -- just not in /etc/init.d -- retooled to use the SMF DB instead of simple, everybody-know-about-them everybody-knows-how-to-use-them config files.
The issue with serialized vs. parallel boot is the lie of efficiency. The push for parallel is the task that sits idle waiting for an outside event. The thing that camp fails to understand is the possible (and often very real) I/O contention from too many processes reading and writing at startup, which can (and does) make boot actually take longer. It's a fine line they don't know how to walk.
And yet, it's still a decade behind. Low clocked RISC processors are just too damned slow for many modern applications. Sure, it can run many threads in parallel, but the answer from each one will be 5x (or more) slower than their cheap, commodity Xeon and Opteron competition.
(@ 20k+ for a SPARC T4 server, I can buy a dozen (or more) x64 servers)
IMO (shared with many of my peers), Solaris 10 is when it died. And it's entirely because of SMF. It has too much of a Windows Stink(tm) to it... want to change a service configuration, run the SMF equiv of "regedit". The init system has a database -- it replicates ("rolling backup") at startup -- instead of clearly defined, easy to understand, and trivial to edit configuration files. While SMF does add one or two notable features -- automatic dependency trees, parallel startup, error handling... Most of it has already been done with the existing (shell scripted) init framework. And parallel is one of those things that looks good on paper, and sounds good in the conference room, but when actually done just makes a mess. (one any windows users should be very familiar with... the complete inability to use a system for several minutes post-boot because 87 applications are thrashing the disk all trying to start at once. Yes, it's annoying having to sit and watch the machine do nothing for a minute waiting for sendmail's dns lookup to timeout to finish booting, but the start-almost-everything-at-the-same-time alternative is *worse*)
Even better... Chrome won't even run the java plugin 9 times out of 10. (even then, you have to OK it's running of any applet)
You've completely missed the part about UNLESS YOU BUILD IT YOURSELF... windows is more or less a "built yourself" installation as there aren't any "system" pythons -- they're going to put stuff where the porter wants it, which is self-contained in 99.9% of the versions I've heard of. The distro provided versions (esp. Redhat) intentionally have common search location(s) that can be a pain to override.
If you're a python developer, then you'll very likely have numerous local builds without such issues. For common end users, no one is going to go to all the trouble necessary to side-step the system python, or build their own self-contained version. (an app provider might, but I don't know of *any* that do -- outside windows, and many windows python apps simply include a "step 1: install activestate python x.y.z")
Said by someone who clearly has not tried to run multiple versions of python on the same system. Unless you built the non-system versions specifically to NEVER look outside your own locked down, version dependent install, it's going to touch system-wide, non-versioned areas, and in the process either itself fail, or touch something causing the system python to fail. And when your system package manager depends on he system python, you've created a lot of work for yourself.
This is entirely why over 90% of cases, the python in use is the one that shipped with the distro. (since windows doesn't ship with python, there are far less non-versioned overlap.)
Building it yourself can also be a bigger pain than upgrading the OS. Say you need py3 on an old redhat 9 (or centos 4) platform. Good luck, as it'll require building/upgrading hundreds of libraries and additional dependencies. (this is why we couldn't upgrade trac without rebuilding the server.)
Indeed. That's why you don't cut the car off after driving around at WOT. (Also, the ECU keeps various cooling pumps running after the engine is cut off.) As I understand it, this is how VW still does it. It's lasted 13 years and counting. (it's nearing 70k miles now, so it should fly apart like clockwork. most likely on track at VIR; followed by the insane bill for spilling oil all over their precious new track.)
It'll still have an oil pan, and several quarts/litres of oil. The rings are only one of many places where things touch. Also, that oil is one of the things cooling the piston. (and in my car, cooling the turbo)