minio VS Samba

Looks like minio added this in 2022:

https://github.com/minio/minio/pull/15433

We have this example of docker compose you can adapt to be larger https://github.com/minio/minio/blob/master/docs/orchestration/docker-compose/docker-compose.yaml

>Again, here you seem to be arguing against a strawman that doesn't know that blocking the IO loop is bad. Try arguing against one that knows ways to work around that. This is why I'm saying this rule isn't true. Extensive computation on single-threaded "scripting" languages is possible (and even if it wasn't, punt it off to a remote pool of workers, which could also be NodeJS!).

Very rare to find a rule that's absolutely true.. I clearly stated exceptions to the rule (which you repeated) but the generality is still true.

Threading in nodejs is new and didn't exist since the last time I touched it. It looks like it's not the standard use case as google searches still have websites with titles saying node is single threaded everywhere. The only way I can see this being done is multiple Processes (meaning each with a copy of v8) using OS shared memory as IPC and they're just calling it threads. It will take a shit load of work to make v8 actually multi-threaded.

Processes are expensive so you can't really follow this model per request. And we stopped following threading per request over a decade ago.

Again these are exceptions to the rule, from what I'm reading Nodejs is normally still single threaded with a fixed number of worker processes that are called "threads". Under this my general rule is still generally true: backend engineering does no typically involve writing non blocking code and offloading compute to other sources. Again, there are exceptions but as I stated before these exceptions are rare.

>Here's what I mean -- you can actually solve the ordering problem in O(N) + O(M) time by keeping track of the max you've seen and building a sparse array and running through every single index from max to zero. It's overkill, but it's generally referred to as a counting sort:

Oh come on. We both know these sorts won't work. These large numbers will throw off memory. Imagine 3 routes. One route gets 352 hits, another route gets 400 hits, and another route gets 600,000 hits. What's Big Oh for memory and sort?

It's O(600,000) for both memory and runtime. N=3 and it doesn't even matter here. Yeah these types of sorts are almost never used for this reason, they only work for things with smaller ranges. It's also especially not useful for this project. Like this project was designed so "counting sort" fails big time.

Also we don't need to talk about the O(N) read and write. That's a given it's always there.

>I don't think these statements make sense -- having docker installed and having redis installed are basically equivalent work. At the end of the day, the outcome is the same -- the developer is capable of running redis locally. Having redis installed on your local machine is absolutely within range for a backend developer.

Unfortunately these statements do make sense and your characterization seems completely dishonest to me. People like to keep their local environments pure and segregated away from daemons that run in a web server. I'm sure in your universe you are claiming web developers install redis, postgresql and kafka all locally but that just sounds absurd to me. We can agree to disagree but from my perspective I don't think you're being realistic here.

>Also, remote development is not practiced by many companies -- the only companies I've seen doing thin-clients that are large.

It's practiced by a large amount and basically every company I've worked at for the past 5 years. Every company has to at least partially do remote dev in order to fully test E2E stuff or integrations.

>I see it as just spinning up docker, not compose -- you already have access to the app (ex. if it was buildable via a function) so you could spawn redis in a subprocess (or container) on a random port, and then spawn the app.

Sure. The point is it's hacky to do this without an existing framework. I'll check out that library you linked.

>I agree that integration testing is harder -- I think there's more value there.

Of course there's more value. You get more value at higher cost. That's been my entire point.

>Also, for replicating S3, minio (https://github.com/minio/minio) is a good stand-in. For replicating lambda, localstack (https://docs.localstack.cloud/user-guide/aws/lambda/) is probably reasonable there's also frameworks with some consideration for this (https://www.serverless.com/framework/docs/providers/aws/guid...) built in.

Good finds. But what about SNS, IOT, Big Query and Redshift? Again my problem isn't about specific services, it's about infra in general.

>Ah, this is true -- but I think this is what people are testing in interviews. There is a predominant culture/shared values, and the test is literally whether someone can fit into those values.

No. I think what's going on is people aren't putting much thought into what they're actually interviewing for. They just have some made up bar in their mind whether it's a leetcode algorithm or whether the guy wrote a unit test for the one available pure function for testing.

>Whether they should or should not be, that's at least partially what interviews are -- does the new team member feel the same way about technical culture currently shared by the team.

The answer is no. There's always developers who disagree with things and just don't reveal it. Think about the places you worked at. Were you in total agreement? I doubt it. A huge amount of devs are opinionated and think company policies or practices are BS. People adapt.

>Now in the case of this interview your solution was just fine, even excellent (because you went out of your way to do async io, use newer/easier packaging methodologies, etc), but it's clearly not just that.

The testing is just a game. I can play the game and suddenly I pass all the interviews. I think this is the flaw with your methodology as I just need to write tests to get in. Google for example in spirit attempted another method which involves testing IQ via algorithms. It's a much higher bar

The problem with google is that their methodology can also be gamed but it's much harder to game it and often the bar is too high for the actual job the engineer is expected to do.

I think both methodologies are flawed, but hiring via ignoring raw ability and picking people based off of weirdly specific cultural preferences is the worse of the two hiring methodologies.

Put it this way. If a company has a strong testing culture, then engineers who don't typically test things will adapt. It's not hard to do, and testing isn't so annoying that they won't do it.

The answer is here https://github.com/minio/minio/discussions/17543

You've already helped me here https://github.com/minio/minio/discussions/17543. Thank you very much once more.

You say protocol alternative, but assuming you're more concerned with AWS as the host than S3 as the protocol you might try https://github.com/minio/minio

If you do feel an aversion to the protocol then the rclone backend list would be a good starting point

https://rclone.org/overview/

Seems like you want object storage. S3 would be the goto suggestion here, but you said it needs to run on prem so perhaps MinIO.

You could refer to big OSS project Makefiles to take a look, what could be there, for example: https://github.com/minio/minio/blob/master/Makefile

Backblaze's B2 is compatible with AWS S3 that also implemented in selfhosted minio

The TLDR is that you create the filesystem on Linux/Raspberry Pi. Then you "export" that file system via some software to remote computers. You can use Samba (https://www.samba.org/) to create CIFS shares which can be mounted by either Linux or Microsoft Windows devices. There are of course other software/protocols you can use to export the filesystems like NFS, iSCSI, CEPHFS, etc; but these are a bit more complicated than what a novice can deploy. I would start with Samba/CIFS and then branch out once you get more experienced.

You could try to use samba via cgo.

I think you want a CIFS/SMB client? A quick search turned up smbc, which looks like it does what you want. All three crates are based on libsmbclient, which is a C implementation from the Samba project.

Remember kids, there is always Samba.

> First, the article doesn't say that "Linux is not ready for the desktop" - or concern itself with this as an abstract question.

Well, it does, but in a sarcastic manner:

"Yeah, let's consider Linux an OS ready for the desktop :-)."

> Also, I find the "GNU/Linux is already ready for the desktop; I and others use it" argument tired. I've used GNU/Linux for the desktop in 1998, but it sure as hell wasn't ready then.

Conversely, that it doesn't work for certain people does not mean that "it is not ready", which the post does state (sarcastically) as I pointed out above.

> Many use cases aside...

I'm not sure how the browsing, docs and email is miserable, maybe you can expand on that. The video editing is indeed a bit limited from my experience too. However, I don't think "limited proprietary options" is a problem. The community largely and specifically avoids proprietary software. Proprietary incursions into the community are generally seen as a negative thing. And for the lack of codecs, software patents for the most part are to blame.

And then it just comes to my original statement; many things stated in the article are non-issues to most Linux users or just falsehoods:

- Neither Mozilla Firefox nor Google Chrome use video decoding and output acceleration in Linux.

Firefox does.

- NVIDIA Optimus technology is a pain

NVIDIA is a pain.

- You don't play games, do you?

I do.

- Linux still has very few native AAA games.

So "it's not ready" because it doesn't have AAA games? What a pitty.

- To be fair you can now run thousands of Windows games through DirectX to Vulkan/OpenGL translation (Wine, Proton, Steam for Linux) but this incurs translation costs and decreases performance sometimes significantly.

No, not 'significantly' for dxvk.

- Also, anti-cheat protection usually doesn't work in Linux.

For good reason. Blame the dev, and don't make it work on Linux.

- Microsoft Office is not available for Linux

Thankfull.

- LibreOffice often has major troubles properly opening, rendering or saving documents created in Microsoft Office.

And whose fault is this? Use ODT.

- Several crucial Windows applications are not available under Linux.

Thankfully. Also, 'crucial' is subjective.

- In 2022 there's still no alternative to Windows Network File Sharing.

It's available since 1992: https://www.samba.org/

- Linux doesn't have a reliably working hassle-free fast native (directly mountable via the kernel; FUSE doesn't cut it) MTP implementation.

I can transfer files to my phone just fine.

- Too many things in Linux require manual configuration using text files.

No.

etc.

I have a media server that runs ubuntu, and today I wanted to copy some files off of it from my windows laptop. But the samba shares weren't showing up in file explorer (but they showed up on fine on my macbook).

brew info samba samba: stable 4.16.0 (bottled) SMB/CIFS file, print, and login server for UNIX https://www.samba.org/ Not installed From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/samba.rb License: GPL-3.0-or-later ==> Dependencies Build: [email protected] ✔ Required: gnutls ✘, krb5 ✔ ==> Caveats To avoid conflicting with macOS system binaries, some files were installed with non-standard name: - smbd: /usr/local/sbin/samba-dot-org-smbd - profiles: /usr/local/bin/samba-dot-org-profiles ==> Analytics install: 1,477 (30 days), 3,287 (90 days), 6,917 (365 days) install-on-request: 1,459 (30 days), 3,246 (90 days), 6,863 (365 days) build-error: 5 (30 days)

The best thing about net send is, it's entirely unauthenticated -- or at least it was, back in the day. It says "User X on Machine Y" sent this message, and Windows will indeed make sure to tell the other machine who sent the message. But if someone were to reverse-engineer the Windows filesharing and related protocols and turn these into a nice suite of open source tools, nothing would force those tools to tell the truth about which user or machine was net-sending.