So their only argument is the "slippery slope" one. That's pretty weak given how difficult it was to get these rules passed.
Also, in Verizon v. FCC SCOTUS essentially reinforced the Chevron doctrine even more. So there essentially is no slippery slope at the FCC. They don't require a gradual rules change procedure, there is no slippery slope for them to fall down.
The new rules are very clear that broadband providers are not subject to rate setting.
>the Order makes clear that broadband providers shall not be subject to utility-style rate regulation, including rate regulation, tariffs, and last-mile unbundling.
>Universal Service Contributions:
>the Order DOES NOT require broadband providers to contribute to the Universal Service Fund under Section 254. The question of how best to fund the nation’s universal service programs is being considered in a separate, unrelated proceeding that was already underway.
As a bay area resident who regularly has to listen to people whine about 'all them outsiders moving in', I have no sympathy for the residents of MV. Build some dense housing around here and stop whining. We don't all need ranch homes with 3 parking spaces. Build up, build dense, and build mass transit.
> “Our problem is that we have too many good jobs,” said Leonard M. Siegel, a 66-year-old environmental activist who was recently elected to the City Council. “Everyone else wishes they were in our situation, but it’s a crisis for the people here.”
If this person is actually an environmentalist then they should welcome my message of build up, build dense, and build mass transit. Per-capita carbon production goes down as density goes up. Low-density urban living, think suburbs, are terrible at keeping per-capita carbon production low. An actual environmentalist would welcome an opportunity to develop dense urban environments free from a reliance on fossil fuels.
If you want to have a low carbon footprint; live in a place like Manhatten, eat vegan, sell your car and don't travel. In other words, if you claim to want environmental policy, you should be working to make that lifestyle accessible to more people.
> “Nobody wants change,” said Gilbert Wong, a councilman in Cupertino, Apple’s hometown.
I'm sure if I told this person they were a conservative they would take offense. But what other way is there to read this? These people are misappropriating the term conservationist. We're interested in protecting the trees, not your lawn.
Places like Mountain View or Palo Alto could be examples of a new kind of sustainable dense urban living. Instead they're completely wedded to automobiles and a mid 19th century obsession with detached home ownership.
Exactly. It's a travesty that Silicon Valley looks like a suburb in 2015. It should've been a great example of a dense, clean, urban region, which would also mitigate the commuter problems and the pressure on San Francisco rents.
This is one thing Vancouver has going for it: density. There's far more for-sale development than necessary and nowhere near enough purpose-built rental buildings, but at least the new development is more 100+ unit condo towers in the same square footage as four single-family homes.
That, plus new investments in public transit (and, hopefully, more to come) means more walkable neighbourhoods, more services more accessible to people, and fewer 90 minute commutes on car-clogged freeways to get to a choked downtown core and $25/day parking fees.
Vancouver is trying to be a lesson to the world in sustainable, eco-friendly living, and I'm really hoping that we can make it happen.
> If this person is actually an environmentalist then they should welcome my message of build up, build dense, and build mass transit.
Did you actually read the story? Later, it says:
"Google’s headquarters proposal does not include any plans for housing. But the company has told the City Council that it wants housing, and lots of it. Councilman Siegel, for one, agrees. He wants to amend the city’s plan to allow at least 5,000 new housing units."
Maybe we have different definitions of what dense means. But 5,000 housing units is barely a fraction of what MV needs. They should be looking at a number closer to 50,000. As should the other MV communities.
Replacing man pages because 'they look old' is a terribly stupid idea.
How about we replace them because there is something better? Or because they no longer fill a need?
Things that are old and work are not to be messed with. Frankly, if you don't get that, I don't want you, or anyone else who thinks like you, making decisions about any UNIX I might work with.
I lament the poor documentation on Linux, and OSX, and I lament the FSF's obsession with info pages. There's nothing wrong with man pages. Maybe we don't need groff to prepare them, but we need man pages.
> Replacing man pages because 'they look old' is a terribly stupid idea.
I fully agree, and it's not what I meant to say. What I meant is writing new pages in a newer language (insert random lightweight text based format, preferably one where the 'see also' part is linkable) and groff is simply deprecated and supported as well. Since there is currently support, why do we need a maintainer? That is my question.
> Things that are old and work are not to be messed with.
Agreed, so what's the maintainer going to do?
> Maybe we don't need groff to prepare them, but we need man pages.
Once again, I agree. Sorry if I sounded like man pages are unnecessary, that is not what I meant.
> What I meant is writing new pages in a newer language (insert random lightweight text based format, preferably one where the 'see also' part is linkable)
A little bit of manpage history:
Roff has been around since the beginning of Unix (in fact, the group at Bell Labs who developed Unix got funding by convincing managers they could come up with a good typesetting system). Roff supports a variety of macro sets; for a long time, the most common one for manpages was the “man” macros.
In the early 1990s, BSD came up with the “mdoc” macros, which are a significant improvement over the original “man” macros. mdoc is inherently semantic, and allows easy searching and conversion to other formats, including HTML. You can search for based based on function return type or argument type, program authors, include files and environment variables used, and many more. mdoc pages natively support hyperlinking, including links to other manpages, links within the same manpage, and external hyperlinks.
Mdoc is a very pleasant language, and since it’s used in roff you can combine it with other macro sets like tbl (for tables) and eqn (for mathematics). It supports UTF‐8, it can easily be converted to PDF and/or semantic HTML, and provides great searchability. It’s well‐documented and widely supported (mdoc pages are supported out of the box on any system using mandoc or groff for manpages, meaning Linux, OpenBSD, FreeBSD, NetBSD, Mac OS X, Illumos, Minix…).
Okay, I didn't know all that. Perhaps groff is a better language than I was aware of and there is sure something to say for keeping it available.
But is it really all used? I have never heard of searching man pages by e.g. return type (in section 2 or 3 I assume this would be), nor does hyperlinking work (perhaps due to the pager, but still). If only 1% of the people use it, then either it's up to them to maintain it or we just deprecate it in favor of a new system.
And by the way, the new system doesn't have to be only one language, it can be some generic language that other languages can "compile" to if you have the right packages (just like markdown can be parsed to the current man page language).
As for hyperlinks, this of course depends on your output format. less(1) in a terminal doesn’t do hyperlinks. HTML output will, such as in this page: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/...
And a distribution could, for example, configure man(1) to trigger Lynx (or even Firefox) looking at Mandoc’s HTML output.
These toolchains are still being actively developed and improved (semantic search, for example, has only been around for a couple years despite the format theoretically supporting it since the beginning). I try to do my part by contributing manpages to projects that don’t have one, converting to mdoc macros when practical, and explaining the great featureset available. The best part is that it is so widely supported—at worst, mdoc falls back to the manpage infrastructure we have now; deployment of a new toolsuite is not a problem compared to converting to some brand new format. At best, it supports all these great new features, and it does so today!
> I have never heard of searching man pages by e.g. return type (in section 2 or 3 I assume this would be).
I'm not sure what you mean by return type, but if you want to, I think you can section your manpages however you want; i.e. you can have section 1 be 'games' instead of 6 if you want to, it just makes installing manpages more difficult.
I agree with your first paragraph, but not so much with your second. This is one reason why people pay good money for production load balancers. This is also why people run independent scripts to retrieve test pages on their production servers, and monitor in general.
This is not a solved problem, but it's also not a novel problem. It's a problem that I've faced before, and it requires decent monitoring to catch.
Disk space may be cheap but limited. It just makes no sense whatsoever to just put a lot of files on my disk i will NEVER care about. NEVER.
And if i need them, i will install them. Usually i only want a freaking binary to run.