abenedic

>not an inherent limitation of all backlit displays everywhere.

This may be true, but in my experience(not very wealthy, typically sub $400 devices) the presets are set such that 0% backlight in the OS is glaringly bright. I cannot turn it down without rooting the device.

I have my own ideas on why UEFI sucks, mainly around utf-16 and such, but I wouldn't really consider it bloated compared with some BIOS implementations. What is your objection to it?

> improperly generalizing what seemed to be their experience with $500 laptops to also argue against high-quality eInk, OLED and IPS LCDs.

And what Grad student can afford those at [Insert State University]. I was a PhD student in math not long ago, and vastly preferred paper books, and even printed out articles. It is way way easier on your eyes than something actively blasting light. Maybe in 20 years high quality e-ink will be cheap enough, but that has been promised since forever.

ish, you can use cmov for some stuff.

I have been doing a lot of assembly programming, and I can't help but agree with this. It is crazy how simple x86 assembly language programming makes checking overflow compared to C.

>some kind of nationalistic pedestal of overdramatic belief systems that make you Korean

As I said think of it more like regional pride in barbecue. People from memphis don't think their barbecue is their identity, but if you insult it or say that Memphis barbecue sucks they defend it about as much as I have seen people in Korea defend fan death when my friend questioned it.

It is not a good practice to paint with a brush so broadly. Americans believe Russia did no election meddling.

You can be dismissive of fan-death, but please know that the people who believe in it do so more out of national identity than reason. I have met many very smart lovely people who believed in it. Think of it more as regional pride in local barbecue than an actual belief. That said South Korea is far too hot in the summer to have a fan shut off automatically.

The programming model for c ffi that lua uses is, I think, a little nicer.

I am sorry if you are not aware of history, but such a comment is very laughable where I am from.

> (I'm open to new clients btw)

I am not meaning to be offensive, but I really wish I could master the art of sales. I have some trouble adding in a sales pitch in an informative or casual setting. So you have any resources you would recommend for learning how to sell yourself?

[Sorry if this does not make much sense I am still learning English]

I totally agree with you, I personally love single file implementations.

I was just trying to explain what I thought his argument was against them, since I don't think he really explicitly stated it outside of generally speaking of maintenance issues. He just said he would prefer to contribute patches to a project that had multiple files and a makefile based build system.

I was assuming his argument was about the future directions the project could go, which I can see as being a valid criticism. As I said the main issue with a single file implementation is that potential users may end up using parts of the implementation instead of just the public facing interface you would like them to use.

I would like if when people did this they automatically had it compile the library with -ffunction-sections and -fdata-sections. This would make my life way easier, and if anyone is reading this, please add these flags. Combined with stripping the executable afterwards you can make things way smaller for embedded systems.

There seems to be several different discussions which are taking place as a response to your comment. It might be good to have a more consolidated reference since different people are attacking different aspects of your argument, so of which are a little unfair.[I am not a native speaker so I may have misunderstood some points or will misrepresent them]

Reasons why people like single file libs:

* Easy for a beginner to use.

* No non-obvious dependencies. (check includes to see them) * Easy to repackage for multiple OS's

* Easy to understand since each reference is in the same file.

* Typically simpler and have fewer features(which can help one focus on the main issues.)

* No need for either static or dynamic linking, although it is basically the same as static linking in some ways.

* Eliminates the need for dependency management.

Reasons against single file libraries:

* No isolation of components. (The interface and implementation are in the same file)

* Adding new feature may make the library too complicated(which can lead to some features being denied)

* A bit harder to maintain. Since the interface and implementation are the same, some users may depend on internal interfaces. Which can inhibit changes needed for performance.

* May encourage bad behaviour, since the user need never learn to link against a third party library. If the culture changes enough there may be many people contributing who are not able to use standard tools in the standard way. (The idea that beginners should learn the culture that is used by the toolmakers.)

Hopefully this is useful for someone, and I hope I did not misrepresent any opinions.[Also huge fan of Drew]

I think, not to put words in his mouth, that he is objecting to the idea of single file libraries as inherently good or better than a multi-file library. I think the objection is more about future design choices the maintainer will make. If you want to keep it single file, it may be necessary to avoid adding some features which are too complex.

Complex features usually necessitate modularization, which is against the idea of the single file library. Modularization in c and c++ is very poor and based on having multiple files, some of which represent the interface and others that represent the implementation. I at least partly think this is his objection.

I am not sure of a prominent code base that does this exactly, but some people do similar things with "amalagmated builds". Like https://www.sqlite.org/amalgamation.html

You should really be careful about c preprocessor macros when you do things like this with .c files. You should always undefine any macros defined in a file which are not properly namespaced(as much as C allows for pseudo namespacing).

Right, it is almost always possible to do anything. In practice I would rather have to change the includes on one file to get it to compile with musl rather than change the includes on 10+ files each with a different change. It is a matter of degree not kind of difficulty. But in general I always will prefer the issues that arise from a single file implementation rather than the issues from many files.[Sorry if this is phrased poorly, I am not a native speaker.]

It makes it easier to relink against a different standard library like musl. Or for cross compilation. The fewer files to deal with the fewer places I have to look for issues in porting.

I don't really know why you are being downvoted. There are a lot of string libraries that do not work well with Unicode strings. If you natively speak any non-European language it can be hard to use those libraries to effectively solve your problems. Not to bad mouth this project, but we don't really need a fast incomplete library.

He means Ragel. https://www.colm.net/open-source/ragel/

> every joke is actually mean

What is a cow's favorite form of entertainment?

Going to the moo-vies.

A chicken walks into a library, walks up to the circulation desk and says "Bok." The librarian is confused and looks around, the chicken says "Bok" again.

The librarian asks "You, want a book?" The chicken replies "Bok."

The librarian grabs a book from the return pile and hands it to the chicken. The chicken puts it under its wing and walks away.

The next day the same chicken comes back in and says "Bok. Bok."

The librarian looks at the chicken and says "So, you want two books?"

The chicken says "Bok. Bok." The librarian hands the chicken two books and the chicken puts them under its wing and walks away.

On the third day the librarian decides to follow the chicken to see what it is doing.

The chicken comes in and says "Bok. Bok. Bok."

The librarian asks "So you want three books?"

The chicken says "Bok. Bok. Bok."

The librarian hands the chicken three books and the chicken puts them under its wing and walks away. This time the librarian follows the chicken over fields and valleys, through a forest to a large pond. In the middle of the pond is a frog on a lily pad.

The chicken takes one book from under its wing and throws it to the frog. The frog catches it, looks at the cover and says "Readit. Readit. Readit."

Does anyone know of a good up to date guide on QEMU? I have run into some bad old information.

It would be interesting to see the same post in 20 billion years if cosmic expansion continues.

I always have a small problem with trying to define art, and relate it to science. It never seems to go well.

Unicode stuff? I am not super familiar with their stacks, but perhaps some marker is wrong.

What will be interesting over the next 20 years is how legal weed will impact addiction rates.

So, this is old, but pretty cool. I really like his VR experiments though.

Did you mean SaaS? Or is this about some other web thing?