Forgot your password?
typodupeerror

Comment: Re:It's all about timeframes... (Score 1) 101

by Antique Geekmeister (#46764007) Attached to: How 'DevOps' Is Killing the Developer

> Have you ever noticed that companies locate their research divisions away from the day-to-day operations divisions? It is to keep the timeframes separate.

No, it's turf building and budget protection. By segregating the developers from devops, devops can _hide_ their resources and keep them sequestered from developer requests. And putting the systems into a "requests go to managers, and only then to devops" makes the managers vital to allocating resources. It can protect their team from excess pecuniary demands, but far too often it's used to make the manager more important to the process than they should be, and grants them personal power over other groups' projects.

I've been documenting a tragic example of this for the past few weeks. I'm afraid the manager is in for a _big_ surprise when they find out that writing run books is their new highest priority, and their personal approval of run books is no longer expected.

Comment: Re:This role exists in any non-software business. (Score 1) 101

by Antique Geekmeister (#46763943) Attached to: How 'DevOps' Is Killing the Developer

> This sysadmin/scripter/system architect/DBA

And then they stop doing _any_ of the tasks well. They don't show up for planning. they don't document their code, because "it's self documenting" or "documentation is unrelable". They say "Just Google It" when most of what is on Google about the task is _wrong_ and written by people who aren't aware of the subtleties. They refuse to mentor, because it keeps them away from the meetings where they can soak up and interfere in _every single groups's projects_ by citing standards that are only in their head, or worse, are only in the mental image of what other people remember they said once about something else.

One of the great pleasures of my professional life is finding these people and educating them in how _not_ to be a micro-managing block to everyone's work: it involves actually documenting the _working procedures_ for daily tasks so other people can do them. Many of them are afraid of the loss of control or possible errors, but the improvement in speed of daily procedures is enormously satisfying.

Comment: Re:I grew a beard (Score 1) 76

No. It's not. The most effective and efficient forms map the face to a uniform shape, almost spherical shape, especially for 3D facial recognition. The resulting consistent transform is *edge* based, not 3d structure shaped. Anything that adds extra edges, or re-arranges them, like makeup that adds eyebrow like dark markings or makes the face strongly asymmetrical consuses the hell out of it.

Comment: Re:Subtle attack against C/C++ (Score 2) 137

by Antique Geekmeister (#46762235) Attached to: The Security of Popular Programming Languages

> C++ (and do a lesser extent C) lose support because of their extremely poor support for utf8.

That's because for most programming, UTF8 is not worthy of support. It's inconsistently used, it arbitrarily increases the of individual. It would be much safer used as only binary strings, not as actual characters which must be parsed and reformatted among different environments. The advent and popularity of UTF8 with its confusing and ill defined management of case and formally POSIX compliant operations such as file naming has effectively slowed system programming by many years.

Comment: Re:we don't know what happened AT ALL (Score 1) 304

> Actually it can't. That's kind of the point of git.

Unfortunately, many git users keep their SSH keys unencrypted on their local hard drives or on network accessible home directories. This means that a careless git admin may have their SSH keys stolen by quite amateur crackers, and leave the public repositories open to quite malicious changes. I've had precisely such discussions with personnel who insist that they trust the people they work with and they have a firewall, so they're not at risk.

Comment: Re:Technically if an NSA backdoor existed (Score 1) 168

by Antique Geekmeister (#46752771) Attached to: First Phase of TrueCrypt Audit Turns Up No Backdoors

The NSA was _able_ put in back doors. According to the report, the build environments were not safe enough and well enough controlled, or verified, to _prevent_ back doors. Given the NSA's strong interest in having one, and their level of skill, I'm afraid I'd have to assume that they did, indeed, create one. Whether a system that is at risk of such a back door is good enough for personal or even business is something you'd have to decide on a personal basis.

It does seem a good step in the right direction for open source tools to _get_ a thorough security audit, rather than merely relying on "many eyes" to ensure security.

Comment: Re:Statistics (Score 1) 180

by Antique Geekmeister (#46739397) Attached to: The Case For a Safer Smartphone

Zipcars are actually a problem this way. I've used them occasionally while traveling, and they've been quite useful. But as is inevitable when borrowing someone else's car, the controls are "intuitively" re-arranged into inconsistent confusion on most of the cars I've used. As a simple safety measure, I try to schedule the first 10 or 15 minutes of any car rental to just find all the controls: lights, emergency blinkers, parking brake, heat and air conditioning, emergency brake, getting the trunk and hood open, cigarette lighter sockets for power connections, radio controls, adjusting the seats, fuel and water and oil nozzles, console displays for fuel and temperature and speed, etc.

Comment: Re:If you can learn to put a beer down while drivi (Score 2) 180

by Antique Geekmeister (#46739361) Attached to: The Case For a Safer Smartphone

We need cars to have safe places to hold the cell phone, possibly tied to the car's audio. While many modern cars have a USB connection to the car stereo and for recharging a cell phone, there is no safe place to deposit your cell phone so it can continue to give directions or be voice controlled. The result is a mad scramble to put your phone down somewhere in the right orientation so it will continue to give good directions. Or worse, flailing around to run your finger across the "accept this call" slider without crashing the car. That part is not helped by voice->text systems, or an ear bud.

Comment: Re:Corporatization (Score 4, Informative) 103

by Antique Geekmeister (#46739193) Attached to: Why the IETF Isn't Working

For an example on the "speed and effectiveness" of corporate standard setting, you need look no further than the Microsoft designed "OOXML" standard. It's greased rails acceptance over the loud protests of competent engineers, and the political process abuse that led to its acceptance, led to Microsoft tools being labeled as "standards compliant" when they clearly did not even follow the OOXML standards that were railroaded through ISO acceptance.

That event led a lot of people to _resign_ from ISO, because the "corporate speed" led to a badly fractured standard which not even its own sponsoring compoany followed or could hope to follow.

IF I HAD A MINE SHAFT, I don't think I would just abandon it. There's got to be a better way. -- Jack Handley, The New Mexican, 1988.

Working...