HN user

lifepillar

128 karma
Posts4
Comments41
View on HN

I'd like to move the cursor backwards and forwards in long commands easier, maybe even with the mouse

In Terminal.app you may alt-click to make the cursor jump to where you’ve clicked. Besides, I use alt-arrows to jump between words: I don’t remember whether that’s out of the box, though. In any case, you may configure the relevant codes in the Keyboard section of the preferences.

Our technology […] collects opt-in customer behavior data from hundreds of popular websites that offer top display, video platforms, social applications, and mobile marketplaces that allow laser-focused media buying.

To me this seems:

1. not mobile specific; 2. totally plausible; 3. despicable in many ways, but “opt-in” makes me think of (a) masterfully crafted fine print in some Terms of Service that would acknowledge the collection of audio, and (b) that this has nothing to do with a phone mic maliciously being turned on without the user noticing, but it’s rather recording from a mic intentionally activated by the user during the normal interaction with an app or web site.

I see that MVCC is still your preferred way of doing CC, and what academic research is mostly focused. I am wondering whether that’s an advantage for in-memory databases specifically.

I was once discussing MVCC vs 2PL with an experienced Sybase and SQL Server guy, and he claimed that, when transactions are implemented properly and the database is well-designed (no surrogate keys, in particular), 2PL leads to better performance and no deadlocks, while “readers do not block writers” leads to lots of aborted transactions in a heavy OLTP workload. I verified that (I should still have the code around): lots of conflicts in PostgreSQL vs smooth concurrent execution with no retries in Sybase and SQL Server.

I have since heard similar opinions from other SQL Server practitioners: they disable MVCC and rely only on good ol’ 2PL.

Thanks for this tool! I found it when Apple started enforcing stricter requirements for certificates, and the commands I was using to create certificates at the time had become inadequate. I have since used mkcert to generate dozen of certificates for my local network, which work on any service and device.

The only drawback of mkcert is that it makes you forget the steps needed to make a certificate!

I wonder whether people monitor resources consumed by processes… A couple of years ago I had installed Gitea, but it was constantly using between 5-10% CPU. I switched to Gogs, and it doesn’t waste CPU cycles. So, I have stayed with Gogs. My needs are minimal (self-hosting for personal use), so I could probably switch to something even more minimal, but so far Gogs works fine.

I have configured local Unbound to use four different open DNS provideds, round-robin, the rationale being each one gets 1/4th of requests. On the other hand, I am sending requests to four providers instead of one, so I have to trust four providers instead of one. What’s better?

It’s not that conflicts magically disappear if you use MVCC. In some cases, PostgreSQL has to rollback transactions whereas a 2PL-based system would schedule the same transactions just fine. Often, those failures are reported ad “serialization errors”, but the practical result is the same as if a deadlock had occurred. And Postgres deadlocks as well.

One thing PostgreSQL would likely not be able to adapt to, at least without significant effort, is dropping MVCC in favor of more traditional locking protocols.

While MVCC is fashionable nowadays, and more or less every platform offers it at least as an option, my experience, and also opinions I have heard from people using SQL Server and similar platforms professionally, is that for true OLTP at least, good ol’ locking-based protocols in practice outperform MVCC-based protocols (when transactions are well programmed).

The “inconvenient truth” [0] that maintaining multiple versions of records badly affects performance might in the future make MVCC less appealing. There’s ongoing research, such as [0], to improve things, but it’s not clear to me at this point that MVCC is a winning idea.

[0] https://dl.acm.org/doi/10.1145/3448016.3452783

Our mission was to ensure that the assets we were working with were usable by someone ~100 years from now.

Is there any published technical document about the choices made by LoC to achieve that goal?

So, when someone comes to you and identifies herself by providing her SSN, name, date of birth, how do you know whether she corresponds to the record with id M or to the record with id N? Or, more likely, to one of the N records, with N>2, with that SSN, name, date of birth?

Thank you for making HexFiend, that’s the top hex editor!

One thing that I really really like about HexFiend is that scrolling is very fast, yet precise and smooth, no matter the size of the file. Is it based on custom classes? Scrolling in macOS used to be quite ok up to several releases ago. Then it became crappy, especially in some apps (AppleScript Editor comes to my mind).

Codd (rightly) recognized two “fatal flaws” [0] in SQL: (1) permitting duplicate rows, and (2) the treatment of missing information (he also criticized the “inadequately defined kind of nesting of a query within a query”, but that addressed 80’s SQL, and I don’t think his criticisms still apply to SQL:2019).

Perhaps ironically, SQL NULLs are modelled directly after his (logically flawed) 1975/1979 proposal [1]. It must be noted, however, that he explicitly considered his proposal “as preliminary and in need of further research”. NULLs in databases are best avoided, or restricted to views (not base tables) and managed with great care (I’d say that they should be used only with the “inapplicable value” semantics [2]).

[0] Fatal Flaws in SQL, Part One and Two, 1988

[1] Extending the Database Relational Model to Capture More Meaning, 1979

[2] Franconi and Tessaris, On the Logic of SQL NULLs, 2012

Take a look at http://www.softwaregems.com/Documents/Student%20Resolutions/.

I will refrain to comment on the quality of Drupal’s schema, but that diagram just shows a bunch of tables and how those tables are connected by foreign keys. What do those connections mean? What other constraints are there in the data? Are they represented in the diagram?

A good database design conveys a lot more semantics. There is currently one ISO standard (ISO 31320-2, key-based style modeling) for database design. Adop ting that standard does not automagically guarantee good designs, but, if used correctly, it helps a lot (it doesn’t help if you don’t have a good grasp of the Relational model, so I would recommend that you would get familiar with that first and foremost).

Most database schemas you’ll find around are rippled with useless ID attributes that are essentially record identifiers (they are not even “surrogates” as many people call them: for the definition of a “surrogate” read Codd’s 1979 paper) and, as a consequence, they are navigational in nature (they resemble more CODASYL structures than Relational models): to connect records in table A with records in table D, you must join with (navigate through) B and C, while in a well-designed Relational schema you might have joined A and D directly. Do you want a rule of thumb to recognized poorly designed databases? Check for ID attributes in every table (there are many other ways in which database design can suck, though).

How do you recognize good database diagrams? They can be easily translated into natural language (predicates and facts), and two (technically competent) different people would translate them in the same way, i.e., the model is unambiguous. Can you say so for Drupal’s schema?

But I find all hell breaks loose when you want to get a slightly different formatting than what's offered. Then suddenly the entire system becomes something you need to fight against.

LaTeX was developed with the goal of freeing the user (a researcher, typically) from wasting time on layout and focusing on content (scientific research, usually).

Plain TeX is much more flexible, but you may argue that it is much lower level (or is it?).

For general typesetting, I can’t recommend ConTeXt enough. Its philosophy is nearer to TeX than LaTeX, and it gives you full control on layout, too. Much smaller package than the full TeX/LaTeX ecosystem. And it’s scriptable with Lua!

It’s a shame that no one in academia has bothered so far to curate a critical, annotated, edition of Codd’s collected works. His impact was immense (for good and for bad, e.g., nulls in SQL) and he foresaw many of the important issues of data management in the years to come (up to nowadays), including the relevance of distributed systems and the need for different ways of looking at data, as sets, as tables, as predicates, as graphs.

Unfortunately, people who knew or worked with him have died or are getting old, so I’m losing hope…

If you have time to invest, go for a TeX variant (LaTeX or ConTeXt). That gives full control over any typesetting detail.

I’d recommend ConTeXt [0] over LaTeX. A minimal document is as simple as

    \starttext
    Start writing here…
    \stoptext
and you can go a long way from there, including making ebooks. Much better than LaTeX for layout control, language support, graphics integration, table generation, etc… It’s also intimately integrated with Lua for your scripting needs.

The documentation is possibly its weak point: it’s rich and comprehensive, although somewhat sparse and at times heavily technical. But it’s worth the effort, IMHO.

You may get inspired by the TeX showcase [1] (not only ConTeXt, but also LaTeX and plain TeX).

[0] http://wiki.contextgarden.net/Main_Page [1] https://www.tug.org/texshowcase/

I attended one of his talks (but not the ones you mention), during which he described how he was approaching the topic. He said he was reading the most important papers on sat problems in chronological order, and implementing each of the algorithms he found along the way. At the time of the talk, he was half-way through the ‘80s, IIRC.

A lesson in commitment and perseverance for me. And a very funny talk as well (Knuth likes jokes!)