Showing posts with label Rant. Show all posts
Showing posts with label Rant. Show all posts

Friday, August 23, 2013

Linux Mint Olivia - 1 week later...

A follow up to my last post Linux Mint 15 Olivia - Observations...

The Good

Xorg/KDE

Xorg has been working beautifully. No memory leaks. No squirrelly issues in performance or attitude. I haven't even had to blow away my $HOME/.kde/share/config/plasma* files even once!

Packaging

I think I finally started to make friends with the packaging system. The stock 'screen' package is left hamstrung with a MAXWIN value of 40. I can't live within the confines of only 40 so this was my catalyst for making this a priority and figuring out. I finally found some decent docs so that I could download the src-deb, extract, fix, compile, repackage, install. Not only that, but there was another package I needed to tweak and it was super easy to download the binary deb file, extract, fix, repackage, install.

The Bad

Seriously?

Also thanks to the Mint teams priorities, I quickly noticed that after fixing your default search engine in Firefox, the search autocomplete is broken.
If Aerobie Inc. paid Tesla Motors to replace the steering wheel in their vehicles with an Aerobie, do you think they should do it? After all, Tesla needs the money, so shouldn't they do it? Because it's such a great idea to have the primary means in which you steer your vehicle be a product that people used to have a little fun with a long time ago. Not only that, but let's make sure if people try to fix the mistake and switch to a real steering wheel, that it won't turn all the way.
#FAIL

Other missing package nits...

The curl package isn't installed by default. Seriously. No, I'm not kidding.
Less ridiculous exclusions that you can find in every other distro, no 'lynx' (which only old farts like me use anyway), 'pcregrep' and friends, 'mc' (again, an old fart utility) and 'whois' (ok, I work at an isp, obviously that would only be important to me).

Sunday, April 15, 2012

Google Groups Advanced Search

It seems I'm not the only one who finds the removal of the google groups advanced search extremely annoying. Threads such as here abound...

The support page is broken and useless because Google's been rolling out interfaces faster than they can write documentation:  http://support.google.com/groups/bin/answer.py?hl=en&answer=46036

Googling for the groups advanced search page turns up a lot of broken search pages (for example: http://groups.google.com/a/webmproject.org/) which have the search form, but yield no results of any kind for any searches.

So, in hopes of helping anyone else out who is looking for this feature, I found this working link buried in the cached version of one of the google groups pages:

http://groups.google.com/advanced_search?q=&

 

When Google took over Deja many years back, they took on the responsibility of maintaining an archive of internet historical significance. It may not seem like much to some, but I love that you can go back and see the first emoticon discussion, or see some of the earliest successful open source, or early posts and discussions from true icons of technology.

Who knows how long that link will keep working before some UX "engineer" will see fit to burn it down completely.  After all, if we're too stupid to handle advanced searching, we're too stupid to care about some old boring old "forum" posts.

Monday, September 27, 2010

Teh maths is fun... (ipv6 rant)

My company just got it's ipv6 allocation.  They gave us a /32.  Let's walk through this math for those of you watching from home.

/32 is the number of bits.  The full length of an ipv6 address is 128 bits.  Represented in binary, this means that the highest possible number is all 1's, for a total of 128 of them:

 

11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

 

To convert this number into decimal, you start way over at the right, and continuously increment by the powers of 2.  The first position is 1, the second is 2, the third is four, the fifth is 8, the sixth is 16, the seventh is 32, and so on and so forth.  If you bother to follow those powers of two all the way out to 128 bits, you end up with a really big number.  170,141,183,460,469,000,000,000,000,000,000,000,000 to be exact.  This is the maximum number of ip addresses able to be assigned out of the ipv6 pool.

Our allocation of a /32 means that, starting from the left, you count out 32 binary bit positions and flip them to a 1, and the remaining 96 binary positions are all 0.  This gives us a total allocation of 79,228,162,514,264,300,000,000,000,000 ip address.  If you were to write me a check giving me a dollar for every one of our ip addresses, you'd need a check that was about 3 feet wide so that you could write out the number in english.  You'd be writing me a check for seventy-nine octillion, two hundred twenty-eight septillion, one hundred sixty-two sextillion, five hundred fourteen quintillion, two hundred sixty-four quadrillion, three hundred trillion dollars.

So, my company has personally been given enough ipv6 addresses to assign every single cell in your body well over 1 quadrillion ip addresses.  Every. Single. Cell.

From what I've been hearing, this is the norm.  They gave one guy a /48 for his websites, of which he has a small handful.  One septillion ip addresses.  For a few websites.

Let's extrapolate that our /32 is the norm for anyone needing more than a handful of ip addresses.  Divide the biggest possible 128 bit number by our /32 allocation.

 

170,141,183,460,469,000,000,000,000,000,000,000,000
÷ 79,228,162,514,264,300,000,000,000,000


2,147,483,648

 

That's the kind of number you don't need any help spelling out.  A little better than 2 billion.  How many ipv4 addresses are there?  Double that.  4 billion, though the way ipv4 has been carved up means that substantially less than that is usable.

It took us 30 years to approach exhaustion of the ipv4 space, though the last 15 years has seen such an exponential increase, the first 15 years is nothing but a drop in a bit-bucket in comparison.

I've argued repeatedly that there's so much ipv4 space that is absolutely WASTED that there really isn't that much of a crunch if they started enforcing utilization standards.  MIT, for example, has 16 million public ipv4 addresses of their very own.  Why?  Because, when it was allocated to them so many years ago, they could get away with it.  16 million.  For a college.  Do they need 16 million publicly facing ip addresses?  NO.

And, of course, there's no place like 127.0.0.1 is there?  Another 16 MILLION ip addresses wasted on localhost.  Why?  Because back when it was assigned, they could.  Who cares, right?  When there's 4 billion addresses, what's 16 million here or there, just between friends?

Xerox, 16 million.  HP, 16 million.  Ford, 16 million.  Halliburton, 16 million.  Prudential, 16 million.  Merck, 16 million.

Do any of these companies need 16 million publicly facing ipv4 addresses?   NO.  That's over 83 million ip addresses wasted right there.  Yes, HP recently purchased a company that produced cell phones.  Do those cell phones need PUBLIC ipv4 addresses?  NO.  The specifics of the wastefulness of the ipv4 space are a separate rant, though.

My point is that this pattern of wastefulness is not only continuing with ipv6, it's getting much, much WORSE.  Insanely sized allocations to anyone who asks for a few ips?  Really?  What good is having this seemingly vast amount of address space, if (going back to the handful of websites example) the wastefulness of this space increases by not 1 or 2 or 10, but TWENTY-FIVE orders of magnitude?

The view from this boat looks a lot like it did 30 years ago.

Thursday, July 9, 2009

Red Hat rant...

> @mjasay:  Putting together a post on the not-so-flawless execution of Red Hat's past. (Weird M&A, etc.) Pls send yr ideas to my twitter name @mac.com

Here's one I'm still a little raw about.

I figured out the hard way one of the ways that Red Hat earns money.  Strong arming, as far as I'm concerned...

I work for a broadband ISP and over the last couple of years we've been moving away from Sun gear and the Solaris o/s to HP blades running Linux.  In preparation for moving my BIND dns servers from Solaris to Linux, I set up up a pair of servers running the stock bind packages for 5.2.  I started by just pointing my 10 anti-spam servers to these two boxes.

The named process crashed in two days.  "socket.c:1649: INSIST(!sock->pending_recv)"  Come to find out, this is a bug that had been fixed a year and a half prior by the ISC BIND developers.  Red Hat will not implement the fix unless you have one of their ridiculously expensive support contracts and open up a case with them.

They keep the model broken because the way the bind rpm packages are created, the start with a VERY OLD version of bind as the base to compile from, then simply apply whatever patches they pick and choose to apply before building the rpm.

I'm usually a proponent of sticking with rpm's for anything like that because it makes things very maintainable.  But since Red Hat holds bug fixes hostage like in this example, I'm compiling from source.  Less maintainable, but the named process hasn't crashed for me and it's been about 5 months now.

As an aside, I ran dnsperf tests against the stock bind and a fresh compile of my own and mine handled 3 to 5 times as many queries per second.  But this only because Red Hat uses shitty ./configure options when they compile, something anyone can tune with a src rpm.


--
Andy Harrison
public key: 0x67518262