A more skilled person that understands all the underlying steps will always be more efficient in scaling up due to knowing where to allocate more.

basically... you always need the skills and the money is the fine tuning.

Nowadays I code for a living, but for sure this is the game that started the spark for me.

It was a great time and I feel that I can always run this game and get back to that childhood feeling.

On the other hand, for mobile apps, there is still a device-specific mentality.

Imagine web apps being built with a different flavor for all the major browsers...

I hope that the same level of standardization comes to mobile apps too with the option to use more device-specific features on top of the generic UI.

- one single machine - nginx proxy - many services on the same machine; some are internal, some are supposed to be public, are all accessible via the web! - internal ones have a humongous large password for HTTP basic auth that I store in an external password manager (firefox built in one) - public ones are either public or have google oauth

I coded all of them from scratch as that's the point of what I'm doing with homelabbing. You want images? browsers can read them. Videos? Browsers can play them.

The hard part is the backend for me. The frontend is very much "90s html".

How can you idiomatically do a read only request with complex filters? For me both PUT and POST are "writable" operations, while "GET" are assumed to be read only. However, if you need to encode the state of the UI (filters or whatnot), it's preferred to use JSON rather than query params (which have length limitations).

So ... how does one do it?

text on the left, render on the right pane

example: https://imgur.com/9rjoMa2.png

I insisted a lot on this unix (ish as it's not pipes) philosophy. It paid off so far.

We can test each cli app as well as make broader integration tests.

`zip out.zip dir/`

This results in a single out.zip file that is, let's say 500Mb (1:2 compression)

If you want to shard it, you have a separate tool, let's call it `shard` that works on any type of byte streams:

`shard -I out.zip -O out_shards/ --shard_size 100Mb`

This results in `out_shards/1.shard, ..., out_shards/5.shard`, each of 100Mb each.

And then you have the opposite: `unshard` (back into 1 zip file) and `unzip`.

No need for 'sharding' to exist as a feature in the zip utility.

And... if you want only the shard from the get go without the original 1 file archive, you can do something like:

`zip dir/ | shard -O out_shards/`

Now, these can be copied to the floppy disks (as discussed above) or sent via the network etc. The main thing here is that the sharding tool works on bytes only (doesn't know if it's an mp4 file, a zip file, a txt file etc.) and does no compression and the zip tool does no sharding but optimizes compression.

We need to separate and design modules as unitary as possible:

- zip should ARCHIVE/COMPRESS, i.e. reduce the file size and create a single file from the file system point of view. The complexity should go in the compression algorithm.

- Sharding/sending multiple coherent pieces of the same file (zip or not) is a different module and should be handled by specialized and agnostic protocols that do this like the ones you mentioned.

People are always doing tools that handle 2 or more use cases instead of following the UNIX principle to create generic and good single respectability tools that can be combined together (thus allowing a 'whitelist' of combinations which is safe). Quite frankly it's annoying and very often leads to issues such as this that weren't even thought in the original design because of the exponential problem of combining tools together.

It also simplifies the stack a lot to have a single set of sensors, so the software becomes mostly: getting good training data (iterative loops from failing production cases) and an efficient training algorithm.

This scales to more than just AD and also can leverage new breakthroughs from academia

I tried it once in an sqlite DB connector with some business logic and simply checking stuff like

  res: DBException | Result = db_handler.some_business_logic()
  if isinstance(res, DBException):
    return res # you can also log or even raise if this function isn't returning exceptions as values
  # guaranteed to be Result type here

- https://gitlab.com/meehai/drpciv-flask/-/blob/main/be/db_han...

- https://gitlab.com/meehai/drpciv-flask/-/blob/main/be/app.py...

For example, this dataset was generated using this tool: https://huggingface.co/datasets/Meehai/dronescapes

I'm quite aggressively trying to "just get the nn.Module" from the public repos that other researchers put up in their overly convoluted frameworks. A simple `forward(rgb_input: torch.Tensor) -> torch.Tensor` is nice, having 100 imports from a generic framework that has versions incompatibilities with everything else is not.

PS: most mains are standalone runnable too, i.e. - https://gitlab.com/meehai/video-representations-extractor/-/... or - https://gitlab.com/meehai/video-representations-extractor/-/...

Comments URL: https://news.ycombinator.com/item?id=41790559

Points: 2

# Comments: 0