nishs

On:

"projects using licenses like the GPL… live under constant threat of having someone take over the project by producing a better version of the code and doing it faster than the original owners."

Yeah, I don't understand what the article is trying to say. Honestly the above seems like a good thing.

> E.g. why can users of GPL stuff not just fork, just like BSD?

A GPL-licensed project can be forked. But, if you release work that uses or is derived from the GPL-licensed project, among other things:

1. you must include or make easily available the source code for your derived work.

2. roughly speaking, the license of your derived work cannot be less free than the GPL license (i.e. cannot infringe on rights granted by the original GPL license).

Releasing work derived from a BSD-licensed project does not have these requirements.

References: https://en.wikipedia.org/wiki/GNU_General_Public_License#Ter...

(edit: and on second glance, sorry, it seems like these details aren't really that relevant to the point of your questions.)

The common BSD-style licenses, 2-clause BSD and 3-clause BSD, are similar to the MIT license. The 2-clause BSD is effectively the same as the MIT license. The 3-clause BSD adds "don't use the names of the original software contributors to promote your derived work."

(The Go programming language and Chromium use BSD-style licenses.)

The Chrome dev rel blog post [1] describes limitations of structuredClone:

* Prototypes: structuredClone discards the object’s prototype chain.

* Functions: structuredClone quietly discards functions.

* Non-cloneables: structuredClone throws for some common values, e.g. Node, Error.

[1] https://web.dev/structured-clone/

Makes sense for the most part with these constraints then. I missed the "primitive types" portion in the original comment.

The following isn't applicable for pure JSON responses, but is applicable for primitive types:

An additional condition for bigint is necessary, which is a primitive type. Otherwise JSON.stringify throws:

  >>> const x = { i: BigInt("0x1fffffffffffff") }
  undefined
  >>> typeof x.i
  "bigint"
  >>> const b = JSON.parse(JSON.stringify(x))
  Exception: TypeError: JSON.stringify cannot serialize BigInt.
  >>>

... and for the symbol primitive, which JSON.stringifys to undefined, and thus can't be JSON.parsed.

This fails, among other scenarios, if `someThing` includes a Date object.

  >>> const z = { d: new Date() }
  undefined
  >>> typeof z.d
  "object"
  >>> const a = JSON.parse(JSON.stringify(z))
  undefined
  >>> typeof a.d
  "string"
  >>>

After the roundtrip, the property `d` is now a string, not a Date object.

I thought it was the other way around? i.e. "NO", in a document that intends "NO" to mean "Norway", is parsed as "False".

wholeheartedly yes; this addresses nearly all the concerns i had in my comment.

the only other concern is the ability and the added time to make changes to these dependencies. what this sometimes means in practice:

in terms of time: you may have to wait for upstream to accept your change. alternatively, one could maintain a fork of the package and replace the dependency to point to the fork while waiting for changes to be accepted, however doing so adds back-and-forth work.

in terms of ability: upstream may reject a change.

after the change is merged upstream, you are required to vet commits in the dependency between the last previously vetted commit and your currently merged commit, all at once, before you can upgrade the dependency in your original project.

There isn't a need for specific ordering of keys in the object representation. But I want to be able to write parts of the toml document in different orders (e.g. "hosts" table before "certfile"; or "hosts" table after "certfile") and still have the same effective object.

from the slides:

> Lots of crates (Rust libraries) available - Don't have to reimplement the wheel:

> lscolors, walkdir, tempfile, terminal_size

i believe this isn't always quite an advantage that the slides make it out to be when implementing tools as critical as coreutils. you typically would want internal packages that you can precisely control.

It's weird that the only way to get the following structure:

  {
    "hosts": {
      "example.org": "localhost:8000",
      "foo.com": "localhost:9000",
      "sub.example.com": "localhost:9002"
    },
    "certfile": "path/to/cert.pem",
    "keyfile":"path/to/key.pem"
  }

is to write the following toml:

  certfile = "path/to/cert.pem"
  keyfile = "path/to/key.pem"

  [hosts]
  "example.org" = "localhost:8000"
  "foo.com" = "localhost:9000"
  "sub.example.com" = "localhost:9002"

and other toml orderings, like in the parent comment, fail.

TOML is a bad file format for human configuration.

For example, in the following file

  [hosts]
  "example.org" = "localhost:8000"
  "foo.com" = "localhost:9000"
  "sub.example.com" = "localhost:9002"

  certfile = "path/to/cert.pem"
  keyfile = "path/to/key.pem"

Ordinary human readers would generally think that the hosts table has 3 entries. But TOML considers certfile and keyfile to also be entries in the hosts table.

TOML has no way to end a [table] on its own; tables continue until EOF or until the next [table].

s/torrent/pirate?

context for unaware: torrents are more general. for example, official releases of open source operating systems, such as debian [1], are available via torrents.

[1]: https://cdimage.debian.org/debian-cd/current/amd64/bt-dvd/

> M2s made $800k+. Why wouldn’t a manager not be motivated to grow his empire?

Possibly by not being singleminded or crazy about money.

Is this an ad for the no-code website builder platform?

Why is the "built with no code" aspect stressed in the post?

> I built a landing page for it using a no-code platform [...] create a professional and functional website without writing any code.

> I was able to easily build a landing page [...] like it was built by a professional [...] power of no-code platforms.

Similarly the post title:

It starts with "no code landing page", doesn't describe the actual startup idea, and mentions the no-code website builder URL at the end.

I agree with your points regarding writing a test. It is one of the best ways, and the right way, to handle the issue.

That said, I think my toy example wasn't the best way to show some of the points I was getting at. Consider a real example, such as this function from file src/net/http/transport.go in the Go source:

        // rewindBody returns a new request with the body rewound.
        // It returns req unmodified if the body does not need rewinding.
        // rewindBody takes care of closing req.Body when appropriate
        // (in all cases except when rewindBody returns req unmodified).
        func rewindBody(req *Request) (rewound *Request, err error) {
                if req.Body == nil || req.Body == NoBody || (!req.Body.(*readTrackingBody).didRead && !req.Body.(*readTrackingBody).didClose) {
                        return req, nil // nothing to rewind
                }
                if !req.Body.(*readTrackingBody).didClose {
                        req.closeBody()
                }
                if req.GetBody == nil {
                        return nil, errCannotRewind
                }
                body, err := req.GetBody()
                if err != nil {
                        return nil, err
                }
                newReq := *req
                newReq.Body = &readTrackingBody{ReadCloser: body}
                return &newReq, nil
        }

When you work with code in or around this function, the existence of the comments tell you what the function guarantees, for example, regarding the closing of the request body. If at some point, there is a bug, it is more likely to be noticed because of the discrepancy between the intentions in the comment and the implementation in the code. Without the descriptive comment, an unfamiliar developer working on this code will likely not be able to tell if something is off in the function's implementation.

Also, as a user of code, it's nice to first know descriptively what guarantees a complex internal function promises from its comment. Then, if necessary, be able to verify those guarantees by reading the function body.

Of course, in an ideal scenario, a unit test is the best way to address things. But this this is a 22 line function unexported function in at 2900 line file, and sadly it appears this function isn't unit tested.

So, given how things are in practice, I argue that the presence of a comment, like here, can help with correctness of code.

Exactly.

Here is another example where a comment can help.

  // Do does x, y, and z, in that order.
  func Do(x, y, z func()) { 
      x()
      z()
      y() 
  }

Sometimes, as here, the comment correctly describes what the code should do. But the implementation does not agree with the comment. Relying on the comment, a developer can confidently fix the bug, or, at least, notice a discrepancy between the intentions, as described by the comments, and reality, as implemented by the lines of code. This is particularly important in complex code. Think: HTTP keep-alive handling, in which many factors, with varying priorities, have to be taken into account (e.g. client hint in the request header, current server load, overall server configuration, per handler configuration).

Sorry for the digression first. (If anyone has different definitions for the ideas here, I would love to learn.)

I think the answers would depend on the types of tests that the term "this" encompasses. From how I understand it, calling something a unit test or an integration test depends on the context of what is is being tested. For example, if a developer is writing a unit test for a HTTP handler, and the handler implementation includes calls to an external database, then one would have to use a mock for the database, in order for the test to be deemed a true unit test [1]. If the developer is writing an integration test for the same HTTP handler, then the database would have to be a real database implementation [2].

On other hand, if the developer were testing SQL queries for syntactical or logical correctness against a database, these tests would want to use a real database implementation. Note that though the test uses a real database, it is still a true unit test [3]. Additionally, note that using a mocked database here would not serve the purpose of the tests, which is to catch syntactical and logical errors against a database engine. This can, of course, only be achieved by using a real database—or, if you insisted on using a "mock", then, by implementing an entire SQL engine, with the exact same quirks as the real database's engine, inside the mock!

On the original question:

> Do you do this in place of unit tests (where you have to mock/stub the DB interactions) or do you do both?

I guess the answer would be: It would depend on the objectives of and types of tests. Do both of them, because some tests, such as unit tests on the HTTP handler, would use use mocks, while other tests, such as the SQL query correctness tests, would use the real database.

[1] A true unit test is one that has no external interactions, neither directly nor transitively, besides interactions with the system under test (SUT). The SUT here is the HTTP handler.

[2] An integration test should include external system interactions, if any. That's what integration means.

[3] The SUT is each SQL query and the its interaction with the database. There are no interactions in the test with systems outside the SUT, so it is still a true unit test.

If an organization making a product has to choose between

(A) mining user data; hyper-optimizing their algorithms for relevance and user engagement; and maximizing revenue

(B) not mining user data; having not-as-engaged users; and having lower revenue

I think the organization should choose option B. If there isn't sufficient incentive generally for organizations to choose option B over A, then the larger question is how can we structure our world to incentivize that? That is what I was driving towards with my earlier comment.

On the consuming side, it might actually be a good thing to sometimes stay bored, to not have relevant content lighting up your face all the time. But that depends on the person's preferences and needs though. Here too, how can we structure the world so that people don't think it crucial to be able to find engaging content when they open an app.

Providing and consuming relevant content shouldn't be a holy grail, or at least should be given less importance.

That's like a more fun-sounding version of Dijkstra's "Computer science is no more about computers than astronomy is about telescopes."

Full series of videos: https://www.youtube.com/playlist?list=PL5E4E56893588CBA8

What is your distinction between the two?

If _this_ is considered a high watermark, that speaks volumes in itself.

Could you describe the costs and problems that might be considered not worth dealing with?

TCP/IP Illustrated and Advanced Programming in the Unix Environment, both by W. Richard Stevens.

The Haskell Wikibook.

More Ursula K. Le Guin.

In Activity Monitor on macOS 12.6 I see “PodcastContentService” running but not “Podcasts” itself. Are you seeing the latter?

Side note: It appears that PodcastContentService continues to fetch data via nsurlsessiond after the Podcasts app has been quit. These outgoing requests by nsurlsessiond—to hosts such as wnyc.org—were made apparent by Little Snitch permission prompts.

Update: PodcastContentService continues to run >5 minutes after quitting Podcasts, so perhaps it's a service that is always running, and maybe is unrelated to OP's question. I haven't checked whether PodcastContentService was running before I opened the Podcasts app.

Update two: I saw the Podcasts app in Activity Monitor a few minutes later. It disappeared within a few seconds though. It seems to have started on its own.

The video is an excerpt from Michael Levin's full talk in the SEMF 2022 Spacious Spatiality series: https://www.youtube.com/watch?v=jLiHLDrOTW8s.

There are many instances and instance operators to choose from. At least one of the choices may be sufficiently trustworthy for many users (e.g. an instance for their city run by someone in the neighborhood). You could also run your own instance.

These options sound better than trusting a corporation.

> The instance operator can see everything because there's no encryption.

What additionally is an instance operator seeing that isn't already public? Are you referring to direct messages and privacy/blocklist settings? Regardless it's no different than having a corporation see (and mine, or sell) this data.

> Quit being so scared.

Unfortunately not everyone may live in a region with multiple internet providers, such that they can switch to a different one if banned.