jcarrano

Someone please explain: if I fork Firefox or Chrome and delete the censorship code, then I publish it online (eg. in github with a download link), then next time I go to France I will get into trouble?

If 20 years of horsing around with a material that does not work did not end their careers, neither will this.

The only one that makes sense to me is the "suggestion", to clearly indicate that it is OK if the code is not changed or that the change is not that important.

For the rest, isn't it obvious when an question is a question or a hint is hint? If you understand English then the meaning of each comment should be clear.

First if all, congrats.

> Apparently everything online about how operating systems and CPUs work is terrible

Then it is time to head for the books. Most of the stuff in the web is not organized and coherent. In particular, the "basics" (whether is CPUs, machine learning, etc) are seldom explained.

The methodology is all wrong, as others pointed out. However image-2023-04-26 is pretty interesting. It has some value.

Android does not count because it's userspace is completely different and in practice it cannot be modified or easily run on different hardware. Same for Chrome OS.

SteamOS on the other hand is an actual GNU/Linux distribution that can be installed in any machine and any improvements that Steam does, e.g. to 3d drivers or hardware support, will benefit the entire desktop Linux ecosystem.

I used to work on a large-ish open source project. When I was bored I used to go bug-picking (not hunting, picking). I'd go and browse the source wherever my intuition told me there was likely a bug and I indeed found a few using with such a "method".

Is there a library that can generate SDFs directly from the font's Bezier curves?

Yes it can- that's the first thing I tried- but it will not iterate forever. The trick is to use indirect recursion:

  <div id="a"></div>
  <div id="b"></div>

  #a,
  #b {
    height: 200px;
    width: 200px;
    border: dashed;
  }
  #a {
    background: -moz-element(#b) no-repeat;
    background-size: 80%;
    border-color: green;
  }
  #b {
    background: -moz-element(#a) no-repeat;
    background-size: 80%;
    border-color: purple;
  }

Some questions are asked expecting a particular answer, rather than the truth. "How long is this going to take" is one of those.

Most software out there follows the "Big Ball of Mud" [1] essay almost verbatim. My (anecdotal) rule of thumb is that after around 10 years of this kind of development, the inefficiency grows so big that development stalls. That happens when the ratio of new features to new breakages approaches one.

Then the company adds more and more developers to work on the same codebase, which will not help because their productivity will be super-slow. Instead they should be working in rebuilding the product.

Of course, at some point doing a huge design and making everything technically perfect from the beginning is wasteful. The main mistake to me, however, is not realizing the long-term costs and that doing it "right" is not so expensive.

One does not even need to design everything, just have enough foresight to not paint oneself into a corner design-wise.

[1] http://www.laputan.org/mud/mud.html

Try reversing the causality: the companies with a very profitable business can afford to have a mess and still survive.

If you wanted to asses the success of privatization based on observations alone, then you would need an alternate universe in which it did not occur.

Also, according to Wikipedia, the largest shareholder for Thames Water is a Canadian public pension fund, so it is at least partially public, just owned by another country.

Yes, that's one of the ways one is supposed to optimize Python. Writing a tiny performance-sensitive part of a Python app in C/C++ is a possibility that many people do not think about when they decide they are going to develop the whole app in C/C++ and can be a much a smarter choice.

I can imagine SVN, but I cannot remember it. I erased the memories.

I don't think the author understand how one is supposed to use branches and DVCS. It also compares an "ideal" situation of "trunk-development" with the worst usage of branches. Those unfortunate enough to have worked with CVS/SVN on a single trunk know that the ideal just does not happen and that by 2023 we know what not to do with branches (and it is perfectly realistic to avoid such mistakes).

> In the branching model, large and infrequent merges can introduce bugs that are hard to identify and resolve due to the sheer size of the changes.

You are not supposed to have branches that diverge too much, and if you do, what's stopping you in a centralized VCS from doing the same? I.e. having a large local changes that you did not upload back to the server. It actually makes the problem worse.

> In contrast, the branching model encourages developers to create separate branches for every feature, bug fix, or enhancement.

It seems the author suggesting not only a reversion the centralized VCS days but also to do it with just a trunk branch, where either each commit is made to the trunk right away (so it must be right on the first try) or you pile uncommitted changes locally.

Using a DVCS and committing to the local version of the `master` branch already counts as having a branched model, except more limited.

> In a trunk-based model, continuous integration becomes more straightforward because your code is committed frequently to trunk, and that's the branch your CI environment is running the build and tests on.

You can run CI and test in any branch you want, and you can rebase prior to running the tests. It is not a big deal.

"With PDF, the map _is_ the territory!" would be a good slogan.

It is not the goal of the CCP to advance China as it is to keep themselves in power.

What's the ultimate purpose? To subsist using the minimal amount of resources? Have you considered that people may want to eat animals?

Every human activity consumes resources. We cannot make the reduction of consumption as a goal in itself. At the end of the road, what that line of thinking leads to is just existing for the mere fact of existing while occupying the minimal space and feeding ourselves enough to meet our required daily values. I do not think that is an existence that makes sense.

Going back to "agricultural land use". Much of the land use for raising animals would not become a lush forest if left alone. There's a reason it is being used for animals and not crops.

Failure to meet a requirement, one of which is user satisfaction, is, by definition, a defect.

It looks pretty much fine, except for the part that says:

> In addition, violations of this code outside these spaces may affect a person's ability to participate within them.

which sort of negates all the other good aspects. If a CoC is a contract or agreement, it should provide guarantees for both sides, i.e. that inappropriate behavior will be punished but also make it exactly clear which things are inappropriate.

There are absolutely no reasons to extend the CoC to spaces outside the project other than to give the enforcers more opportunities to arbitrarily target people.

The callbacks (as in a chain of callbacks) are not natural to a beginner, like a student trying to program a robot. For a GUI, where you set up a callback in response to user input, it is also easy to understand because the program's control flow does not progress as a chain of callbacks.

The input-update-output loop is fine, but you cannot easily combine and nest such loops. For example, in a robot you may have a speed control inner loop, then a path following loop and on top of that a high-level behavior loop. Nesting one inside the others you end up with a hand-baked implementation of a coroutine.

I don't agree. You can handle errors how you like on both approaches. The callback code, however, will get pretty messy once you have a branched control flow.

With coroutines you are using the language's control structures directly. The program counter is your state and a branch is an `if`. With minimal debugger support you will be able to see at which line is the execution on each coro.

With callbacks you would have to inspect which ones are pending, unless you have made the state explicit in a variable.

These is not a huge deal for those who have been programming for a while but for beginners coros will feel more like an extension of the language than something built on top.

I like this, but I also think some of the benefits can be had independently by combining several complementary techniques (in C++).

The allocation can be handled by custom allocators for each object type. You can do only this and you avoid the double de-reference of handles.

If you are fine with double-dereferences and also want to implement extra checks and use less bits for the pointer you could overload `operator->()`, e.g.

struct CompressedPointer {

   uint16_t obj_id;

   Object \*operator->() { return Object::get_by_id(obj_id); }

};

Yes. The callback is not a natural construct (i.e. it does not map well to our intuitive understanding of X is doing something while Y is doing something else).

I'm annoyed when coroutines are reserved for use only in high performance, c10k-type of situations. For example, the KJ library's doc says:

"Because of this, fibers should not be used just to make code look nice (C++20's co_await, described below, is a better way to do that)."

With this "stackless or nothing" attitude we do not have good C++ coroutine libraries outside C++20's.

For me the purpose IS to make the code look nice and I do not care if the coros are stackfull and consume more stack memory. At the end of the day, for my application, I saved more in programmer's time and bugs than I lost in RAM (and I'm on an embedded board with only 64MB)

In a couple of years they will realize that cooking in animal fat was the healthier choice all along.

The problem is that the card reader will be by far the most expensive part of the charger, plus the service fees for using the payment network.

I agree that having 5 apps and needing a phone is bad, but the cost of the card reader will be passed onto you and less chargers will be available.

An NFC-based solution which worked with a single card or a phone would have been better.

Reminds me of Freeman Dyson's anecdote of Fermi:

"I remember my friend Johnny von Neumann used to say, with four parameters I can fit an elephant, and with five I can make him wiggle his trunk." [1]

[1] http://lilith.fisica.ufmg.br/~dsoares/fdyson.htm

Why do they include an optical drive? It's not even optional.

Yes. I'm in Germany and working on chargers and I see as many good ideas as I see awful ones. Another thing I can tell you is that there is a tendency (i.e. "generalization that does not apply to individual cases") to over-complicate stuff.