grive

Ah yes you are right, an interesting point however,

    6.3.2.3 Pointers
    
       3. An integer constant expression with the value 0, or such an expression cast to type void *,
          is called a null pointer constant. If a null pointer constant is converted to a pointer type,
          the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer
          to any object or function.
    
       4. Conversion of a null pointer to another pointer type yields a null pointer of that type.
          Any two null pointers shall compare equal. 

Looking at the definition of NULL:

    7.17 Common definitions <stddef.h>
    
        3 The macros are
        
                NULL
       
          which expands to an implementation-defined null pointer constant;

Meaning that NULL is implementation defined, but is assured by the standard to compare equal to any 0-valued pointer of any type, even if it is itself another special value.

This is only true in C, which is part of why C is less insane than C++.

The two languages should not be conflated anymore.

It cannot buy uBlock origin.

The hacks you have listed have the advantage to be visible. Reading the code, you know whether they are called or not.

The issue with cleanup on scope exit is that this introduces ambiguous code-flows. You would need to demonstrate a strong advantage, beyond making life easier for the writer of the code.

Sorry, indeed this can be useful to know.

You must run weidu where chitin.key is

Modding on linux is a little finicky. For all Beamdog's edition, I wrote a script[1] that would symlink datafiles as a lowercase version everywhere (unless they were already lowercase). After this, all WeidU mods were working okay (at least for BG I&II). I have P:TEE but never modded it however, but the process should be relatively similar.

[1]: http://pastebin.com/raw/nmkSGj0L

Google uses non-standard extensions that only Chrome supports for Gmail and Youtube.

For neutral email apps, Firefox runs perfectly fine. For Gmail, it will be slightly slower than Chrome.

This is not a matter of cost or about whether enough machines are available and they might be shared.

They have several attack scenarii, for which they need to provide countermeasures.

They are listed here: https://docs.clip-os.org/clipos/security.html#threat-scenari...

In this context, Godwin's law is nothing more than a thought-terminating-cliché. These comparisons are not gratuitous: Nazism and the alt-right are both populism, using similar rhetoric to seize power. The apparent apathy in the population is extremely similar.

Many people grew up wondering how Nazi Germany could appear out of nowhere. We are seeing right now the institutions and power balances being eroded in western democracies. This article is about India, but perfectly captures the political, psychological, moral dynamics at play. These are not operating in a vacuum, and while the context is not exactly the same, those dynamics are absolutely similar and should be compared.

This is Poe's law corollary.

And I think that, even simply being exposed to the rhetoric will distord your view. Back when the alt-right was appearing on the Internet, I wanted to engage with the other side to get their story. The more I read and argued, and the more close-minded I found myself to become. I put a stop to it.

Deconstructing your interlocutor's arguments forces you to think in the same binary logic, take the same intellectual shortcuts. I absolutely think that reading radicalized thesis will radicalize the reader.

Centralized services use specially taylored engagement mechanics for people to get addicted to their stimuli.

They do so because there is an economic incentive for them.

Decentralized will not do this, as long as they remain non-profit and strive to stay ethical.

This means that the average user will prefer the unethical and addictive platform. Same thing as with fast-food. Not only do decentralized systems need to be technically competitive and surpass hurdles that centralized systems do not have, but they also need users to be made aware of those issues.

They are necessary but utopic.

I really, really dislike this kind of medium-to-long form article that don't bother to even expose some sort of context (topic introductory line). This is incredibly disrespectful to the reader. You read the first half trying to put the pieces together, while given that this is a proto-longform article (does not have the length, but has the tone), there is fluff added here and there for flavor. This is so frustrating to read.

> The truth, then, is this: our generation was raised with the understanding that the image we portrayed mattered more than who we actually were not out of some malevolent, externally imposed agenda, but because it was actually true. The result was that nothing we ever did felt organic; instead, everything felt like a checked box.

As every generation before? Why even speak about generation here? This seems like an absurd reduction from the author, while this is the kind of thing you learn to recognize as you age and you start seeing the word with your own eyes. Most people becomes disillusioned as time goes on, seeing how much public action is fake.

A much more interesting analysis would be to show how the new engaging platforms distord this longstanding social behavior (signaling), amplifying it or distording it. But to say that they are an "Instagram" generation is giving far too much credit to Instagram. The world was not "disrupted" by Instagram, it was only a lens and a way to capitalize on this behavior.

I could go on with the "lost authenticity", but I feel I'm just trying to justify the time taken to read this empty piece.

Label each coin, divide in three stacks each time, and shuffle meaningfully each time the subsets, to remove uncertainty.

As usual with the SQLite / Fossil developer argumentation, it just seems very biased and far-fetched. Just one example:

> Pile-of-Files Formats. Sometimes the application state is stored as a hierarchy of files. Git is a prime example of this, though the phenomenon occurs frequently in one-off and bespoke applications. A pile-of-files format essentially uses the filesystem as a key/value database, storing small chunks of information into separate files. This gives the advantage of making the content more accessible to common utility programs such as text editors or "awk" or "grep". But even if many of the files in a pile-of-files format are easily readable, there are usually some files that have their own custom format (example: Git "Packfiles") and are hence "opaque blobs" that are not readable or writable without specialized tools. It is also much less convenient to move a pile-of-files from one place or machine to another, than it is to move a single file. And it is hard to make a pile-of-files document into an email attachment, for example. Finally, a pile-of-files format breaks the "document metaphor": there is no one file that a user can point to that is "the document".

More precisely:

> But even if many of the files in a pile-of-files format are easily readable, there are usually some files that have their own custom format (example: Git "Packfiles") and are hence "opaque blobs" that are not readable or writable without specialized tools.

What is advocated here is to transform the pile-of-files in a single SQLite database accessed through SQL queries. So instead of having only a few binary blob, transform everything in a binary blob and force the use of one specialized tool for everything.

> It is also much less convenient to move a pile-of-files from one place or machine to another, than it is to move a single file.

This is not true.

> And it is hard to make a pile-of-files document into an email attachment, for example.

I would not trust someone that had just sent his git repo over email.

> Finally, a pile-of-files format breaks the "document metaphor": there is no one file that a user can point to that is "the document".

A VCS will track source files. Maybe their argument is true for other applications, but for a VCS this is plain useless.

Indeed having only an SQL connector accessing a database is a unified interface to the file. But unifying this to the user means that you have to move the complexity further down, as explained:

> But an SQLite database is not limited to a simple key/value structure like a pile-of-files database. An SQLite database can have dozens or hundreds or thousands of different tables, with dozens or hundreds or thousands of fields per table, each with different datatypes and constraints and particular meanings, all cross-referencing each other, appropriately and automatically indexed for rapid retrieval, and all stored efficiently and compactly in a single disk file. And all of this structure is succinctly documented for humans by the SQL schema.

Yeah, and I don't want to have this complexity managed by a single "entity", I want to have several different tools available to do whichever kind of work I need to do. If I'm working on graphs and need to store them, I would prefer having the ability to read my file directly in my other tools for graph analysis / debugging without having to take the intermediate step of connecting to the SQL database, or redefining a way to work with the SQL paradigm to adapt my file format to the "dozens or hunders or thousands of different tables, fields per table, each with different datatypes".

This point is even more salient regarding grep / awk. The author obviously prefer using the query language of his choice and disregards the variety of tools to work on text, but there are many, many tools available to do all kind of work on it, and believing that

> An SQLite database file is not an opaque blob. It is true that command-line tools such as text editors or "grep" or "awk" are not useful on an SQLite database, but the SQL query language is a much more powerful and convenient way for examining the content, so the inability to use "grep" and "awk" and the like is not seen as a loss.

Is just nonsense. Passing on the file edition conveniently put under the rug, querying the text is usually only the beginning, usually someone wants to parse the output and act upon it, maybe even put back some modified version (sed), and so on.

The author just seems close-minded and living in his own world, unable to imagine that other people might want to work differently.

This reminds me a lot of his rant against git and for fossil, with the exact same bad faith arguments and lack of knowledge about other ways to do things.

> Sadly there is no standard replacement that is widely accepted.

True, but practically: when having access to BSD extensions, strl* are used. If only C standard is available, snprintf is preferred. I have seen C libs that will check for strl* availability, and if not, reimplement them using snprintf.

So for portability, snprintf is the way to go. For correctness, and pushing for their extended use, strl* is nice.

Cambridge analytica is a good example. I guess considering this abuse may be different from a US customer point of view, but for my european sensibility, this is definitely abuse. Furthermore, that Facebook could harvest ghost profiles that could be used in this manner is problematic.

I think it is certainly possible to find cases of identity theft resulting from PII that were leaked in security breaches, made easier by overreaching data collection.

This is already the case...

> Erasing everything I ever wrote down about you is difficult.

It is not difficult to avoid storing data you don't need.

You don't need a user phone number? Easy, don't ask for it.

Of course you argument is that it is difficult to change existing systems to follow this principle. Except that your starting position was that this regulation was about stifling competition, which is thus in direct contradition with this argument.

Existing systems were built on the assumption that "misappropriating" PII was a lucrative thing to do. This led to abuse from the industry.

It seems that the source have already been published and is using open protocols.

I'm actually greatly pleased that my taxes are spent on an app that is actually accessible from the public, and will benefit open source project. This should be the standard way for most government development projects.

Why the distinction? A good law is still a good law, regardless of its origin.

This kind of interface is horrific for the use-case:

https://www.powergrep.com/screens/replace.png

There is such a thing as a cluttered graphical interface, and some complexity cannot just be abstracted away.

> The GUI, which can include arbitrary number of text boxes for command line style entry, is a superset of what the command line can do.

That would be like saying that because I am able to write "First open this app by clicking on the upper-left icon, then click File, new File", would mean that text is a superset of the GUI because it can describe visual cues. An abstraction can always replace another, it does not mean it is a superset of it.

Take the source code for your GUI application, this is pure text. In the early days, there was shell code that would describe terminal GUI of sort to configure the linux kernel. This shell code is still commands read token per token with matching behavior. Because an abstraction can be traded for another (which could be argued to be a founding principle of computer science), does not mean that one is a superset of the other.

> Ah I see, you have a file "new 2.txt", I was a bit confused.

This is highly ironical, given this thread.

Some people seems to advocate for programs to be better than humans at globbing filenames.

I think the idea can work, however the execution is still far from perfect.

Just on the binary search for example, the "balance" representation is re-used to signify the concept of "comparison", however the tokens put in balance are both of the same size, with only an image to differentiate them. So the link is not implicitly made from their size, weight, and the intrinsic feature which makes the one searched token the right one. This would be confusing for anyone trying to understand the algorithm.

Then, you got a first depiction of the problem, with each object being ordered by size. So the initial assumption is that the choice element would be on their size. Afterward, the target token has a star on it, and the generic, incorrect one, a question mark.

That could work, however, they both have the exact same size.

This is only an example of how the concepts used to explain and signify things visually are only partially followed-through. This greatly impairs the impact of the explanation.

And this is only on the binary search, arguably the simplest algorithm depicted here.

How about upgrading your components to extend the life of your hardware? Or reducing the cost of recycling.

Laptops (and electronic devices) are generally an ecological disaster.

Going back to your original post:

> and this was scientifically proven

which renders moot any discussion as you simply did not use the same assumptions. The discussion was about specialist decision systems using correlation as a heuristic for causation. You cannot explore the merit (or shortfalls) of this common practice and its possible effect on policy-making when positing that causation has been proven. This is nonsense.

Have a good day.

Let's assume that higher crime rates are caused by poverty and not by the color of your skin.

Let's say you accept the answer you've received based on your heuristic that black people will statistically commit more crimes.

If a policy was based upon this heuristic, then you would have people living in poverty that would not be subject to the same policy. This is what discrimination is about. Citizens would thus not have the same rights / opportunity.

And the only reason you are accepting this heuristic as "good enough", is because you make the assumption that "you have modelled [enough of] the variables that make up the solution space".

This is not acceptable for policy makers and should be watched for closely in a democracy.

But even on such a tight schedule, you took the time to come to the comment and take part in a pointless thread about a joke.

> i already knew they didnt have their facts strait

Deducing this from this joke alone is irrational, so to be charitable let's assume you had other reasons for dismissing the talk. Why not expose them instead?

Thinking about logic is a discipline of philosophy.

Applied logic is math.

This lag is introduced by vim, to wait for the next keys and see if you are actually inserting them or using mapped key sequence.

It is configurable in vim, but then either you have a lag and you are able to use your key sequence, or you don't and <leader> sequences cannot be used.

So maybe I have something configured that sets it wrong, but I do not see how to reconcile both things.

The only thing preventing me from using <space> is the slight lag it introduce each time <space> is used in insert mode.

It is bearable with ',', but I cannot stand it with <space>.

If it is possible to remove completely this lag (not simply reduce it), then it would be awesome.