TristanBall

I suspect Digicel's marketing dept could give you the realtime PNG population to 6 decimal places.

Joking obviously, but only just.

So at first glance this looks pretty amazing, and you deserve kudos for your documentation quality alone!

2 comments. First, if you're going to lead with statements like "faster than x" - link to your benchmarks. They're not hard to find but I did have to go looking. Second, the skipped "random read" test is a glaring red flag to me, and honestly raises far more concerns than a weak result would have (a weak microbenchmark result may or may not be important, and at worst is something to be considered in engineering, while but trust issues with a vendor are poison ).

I don't know why you skipped the test, maybe it was time, maybe you didn't think it important, maybe you got unusual results and want to retest. But right now it looks like a footgun in what seems to be a very high quality release.

Larping as a dba now, and trust me many of us do know, and its a source of ongoing suffering, but we're often not developers and don't necessarily have the choice of tooling.

Right now the DB I'm paid to babysit provides cli tools that flip between tabular and k/v list output without making that configurable, or a tabular form that doesn't include headers, or a 3rd party tool that will, but has the spectacularly annoying "error on line 1 : multi-line query" issue. Or things that are slow or only talk via generic protocols like odbc etc etc etc

I think you're being a little unfair about the pipe delimited thing though, it's a least worst compromise based on who we're providing the data too - non technical business people, the vast majority of whom use excel or similar tools and couldn't even tell you what "data format" means, let alone configure their systems to parse something else.

Personally I had a bit of an epiphany around the ascii delimiters (us/fs/rs/gs) which work extremely well when the data is ascii/utf-8, and make data interchange between shell cli tools very easy. But they've also invisible and little business software supports them in a friendly way. Telling someone in accounts or market to "use octal 034" helps no one.

And I've resigned myself to using multiple tools, dev with tool 1 with decent error messages, tool 2 for production use because it can actually produce sane output formats.

What I don't have a choice on is which db we use, and it's not modern or cool and honest most things don't even have drivers for it

I suspect part of it is licensing games, both in the sense of "avoiding per core license limits" which absolutely matters when your DB is costing a million bucks, and also in the 'enable the highest PVU score per chassis' for ibm's own license farming.

Power systems tend not to be under the same budget constraints as intel, whether thats money, power, heat, whatever, so the cost benifit of adding more sub-core processing for incremental gains is likely different too.

I may have a raft of issues with IBM, and aix, but those Power chips are top notch.

While this true enough, an ironic side effect of my attending a couple of rounds of sales related negotiation training ( compulsory for everyone at that company ), was to really highlight how calculatingly manipulative this is.

I mean, we kinda all know that anyway, but somehow it reinforced it enough that I know find it actively distasteful.

Even the classic sales approach of buying coffee or a meal feels creepy know, but I've had to relearn to accept it because it's just so hard to fight every time.

When I tell people, the normal response is encredulous "but it's free?". It's really really not, the costs just aren't immediately financial.

(Gifts outside corporate life are generally fine, an actual human wanting to "manipulate" me into liking them more is generally expressing some level of affection. A corporation cannot do that)

Every know and again I get something funny enough that it gets me anyway.. I'm very fond of my all blue Rubic's cube from ibm for example, and I've got a few unbranded water bottles around the place.

Anything else I can't politely refuse just gets binned as soon as I can do so without a fuss.

Perhaps look to your marketing folks rather than engineering.

"Purchasing silver sponsership with [org] as a way to grow our brand awareness" is intrinsically understandable to pretty much any businesses manager.

"Giving away money for something we already have", which is what most technical managers will hear regardless of your actual pitch, is completely inexplicable to many.

It does require that sponsership is even possible, and recurring sponsership may be harder than recurring license fees of course, so its not a sure thing, just an option to try.

On of my favourite hardware investments as a teenager trying to learn c and assembly under dos was a caching hard drive controller.

It made those post crash reboots so much faster!

Talk about solving the wrong problem...

You don't have to change you process, so you can still explain it rationally.

Just leave off the "then I multiplied by 10" part.

Which I did by accident once ( not by 10, but it was still substantial )... but it turned out the customer was delighted because we were still 50% vs their existing vendor.

Enterprise pricing is a farce.

I very much agree with the poster above about vendors disqualifying themselves.. another red flag for me is the Two Suits and Skirt pre-sales Hydra Monster that big vendors love to send around, to scare you into letting them capture all the value that their purporting to provide you.

And yes, the above shows I've been both sides of the fence. I felt it was going to be good experience, and it was, but I have regrets too.

Only on some distro's.

Debian variants tend to link dash, which self consciously limits itself to posix compatibility.

Gosh they look interesting. But ridiculously customer unfriendly product naming, and a website that doesn't provide clear information on international shipping just raises so many red flags for me.

Yup.

And teaching yourself and your tools to use them as delimiters is damn near a superpower for semi-structured/tabular text forms ( aka csv/tsv and co ).

Issues with field definition, escaping, and embedded newlines all but go away.. newlines being the harder ones because some tools just insist on being line based and will hard code variants of cr/lf as newlines.

And they retain their meaning and uniqueness in utf8 ( true of all the ascii control codes ), which is an under appreciated feature imnsho.

Small team with a largely overlapping shared knowledge and attitudes.

Which is not to say it isn't really nice, but I think the chances of it happening are in some way inversely proportional to the number of people involved. It's probably not linear either.

I haven't thought about it in years but my very first pc support traineeship ( 25 years ago!! ) had aspects of this. There was so much shared context for us both that we often left it out, much to the bemusement of anyone else listening.

"Hey, remember we need ", "yeah", "oh and can you pick up", "already did its over there", "oh cool ok can you", "sure, probably after lunch"

It was FUN. But you just can't do it with much more than 2 or 3 people.

Any time I'm doing lego-brick engineering, aka unix style "small tools pipe together", then startup time impacts me most while I'm actively developing the new system.

That process is iterative, usually on a subset of the data, and slow starting tools make my day qualitatively worse.

The final performance matters sometimes, but more often than not it doesn't. 30 minutes or 45 for a batch job? That runs from cron? I don't usually care.

I'm never going to favour slow starting tools unless some aspect of their functionality pays for that cost, or I'm choice constrained, but final peak performance is almost never going to be a factor.

So to me it's not psychological bias, it's economics, and the currency is time, when it's me personally paying it. Semantics maybe, but just writing it of as bias isn't going to help me get things done.

Ha.. my linebreaks got removed!

\ linebreaks are not something I love,and a while ago I started using chained blocks..

These are usually a step between "overely complicated one liner" and structured script, and often get refactored to functions etc if the script evolves that far. But lots don't, and if I just want something readable, that also lends itself to comments etc, this works for me.

{ foo -a -b }|{ bar -c -d -e }|{ baz -e -f }

But I suspect it's not everyone's cup of tea!

Curious as to what's "vastly less practical" in powershell?

That's very, very nice.

I live in a world of Confluence tables, but it's nice to know that not everyone is suffering.

So, I guess it's only me who learned from the comments here that the was a difference between em dash and en dash? Or that they might be different from a hyphen or a minus?

(In my defence, I don't work in any of the specialized areas where it matters, and was raised in a poor, ascii only, western household.)

I will point out that spammers and scammers have been having a field day with this kind of character confusion for years now, and a lot of software still hasn't caught up to it.

On the bright side, the very old school database I babysit for work can be convinced to output utf8, including emoji, many of which render quite well in a terminal, allowing me to create bar graphs of poo or love heart characters, which honestly makes it all worth it for me.

Have you seen vim syntax rules?

I don't think I have ever personally felt older than having someone describe anything docker related as "old-school"

You can buy them in Australia, or at least the bulbs sold here by philips as their "UltraEfficient" range look the same and match the specs of their Dubai bulbs marketing page.

They don't appear to be available in the US though, that's true.

I think I'll get a couple to try for those places where I think "60w incandescent equivalent" is sufficient, although cynical experience tells me to expect 40w at most - but for low single digit wattage power draw I'll accept that in some places.

Mostly I like to see though, so I'll keep buying their 150w equivalent bulbs.

How common are RADIUS deployments that aren't EAP/PEAP based though?

IDK About anyone else but for a very long time anything md5 has been in the same mental bucket as zip or office documents passwords.. a discouragement for the casual user and accidental exposure but not actually secure against any kind of determined attack. ( the accuracy of my mental buckets is perhaps a separate issue )

Although I suppose lots of deployments still go with whatever lowest friction, so maybe lots?

Having worked at an IBM shop, referring to ibm's x, p, i and z series by letter was pretty common, to the point of standard, and same with "our regular ibm customers". ( even if we only dealt with x and p, most folks were at least aware of i and z ) Outside of the IBM ecosystem sure, although once your outside that lots people wouldn't know what an as/400 was if you dropped it on their head so it probably doesn't matter what you call it. ( "expensively fatal" in that specific example, but that's unlikely to be a good marketing term )

I used to get irritated by IBM's naming, and to an extent still do, but it's more things like calling the motherboard the planar and things like that. A lot of the heat went out of that when it occurred to me their usage probably predates "motherboard", but even then keeping it still feels like an attempt to differentiate their stuff to justify higher prices. ( which sometimes is justified, depending on generation and timing, but that'd be true regardless of the nomenclature )

Pfft. Let's talk about the rent before announcing where I live eh?

Last I looked, powershell's startup time on linux was disappointing. Understandable to an extent given it was bootstrapping a bunch of dotNET stuff that would already be there on windows. But slow enough that I couldn't use or recommend it to my team.

It's not in any of the major distress but shout out to csv-nix-tools for a valiant effort in this space https://github.com/mslusarz/csv-nix-tools

Did they say why?

It strikes me that those envs might be particularly prone to corporate inertia, ieg "the current way passed security audit, don't change it or we need to requalify"

It's possibly also harder to rely on a HSM when your software is in a container? ( I'm guessing here tho )

It's been a while since I was testing but sustained FUA ( Force Unit Access or something like that), writes, which are used by some DB's in stead of cache write + sync degrade consumer SSD'S to HDD levels of performance. Perhaps not as slow as HDDs themselves would degrade under the same workload, but certainly 10s of milliseconds.

So yes, visible, extremely so. On drives commonly known as excellent consumer drives and that I myself happily use on a general desktop/gaming PC.

From the limited testing available from my personal budget it would suggest that newer drives are still impacted, although not as badly, and larger drives are ( perhaps obviously ) impacted much less than than smaller ones ( 2tb vs 256gb ). I've seen 2 level drops too.. first when cache/slc writes are overrun, and then a second, when I think the drive is forced into some kind of garbage collection/reorg at the same time.

But all that stuff is very controller specific so it's a little hard to generalize.

But equally, I now buy old enterprise drives, because they work so much better under these workloads at equivalent sizes, even if consumers drives would appear faster according to spec sheets or "drive friendly" benchmarks. I personally use old intel ( 37nn and 46nn series ) but that's mostly just what I know, there are similarly performing models from most enterprise ssd vendors

It first glance this seams really cool, but I have to wonder how much the use of timestamps increases the chances of duplicates.

Long time unix sysadmin here, now working as a dba.

It amuses me quite a lot to see how my code changes when I'm thinking more with my "dba hat" or my "unix hat".

The unix hat will make much more use of embedded environment variables and shell constructs for loops/repetition, the DBA hat leans towards tally tables, sometimes 2 phase sql generation, or stored procedures.

It does make my scripts inconsistent as all hell tho, which is irritating - but the shel, approaches usually flow more easily from my fingers, while the pure sql ones will usually have the edge in runtime performance - shifting back to shell if I need to chunk up a job for parallel processing..

A recent fun one for me was realising the I could lean on the the posix shells printf feature of repeatedly using the format string to consume parameters if there are more parameters that format placeholders.. I can actually pass thousands of lines of sql output to printf and have printf reformat it. Some relatively easy scripting with "split" to chunk up the db output leaves me with something that only runs about 2x slower that raw output from the db (in ksh ), but gives lots of flexibility on things like adding thousands separators to numbers etc, something our db platform is poor at.

Given that most of the line by line iteration is happening inside printf, not in a script for/while loop, it's really quite quick. Haven't benchmarked it against anything yet tho, it's still a toy I wrote while waiting on something else.. but it's got potential.

Judicious use of the old ascii separator codes rather than commas/tabs/pipes/whatever makes the field splitting much easier to deal with too.

Embedded newlines remain a pain tho. For now each chunk of lines gets passed through a perl fragment to turn them into literal \r or \n strings