Borg3

Thanks for info, but I do NOT need network stack. I have my own, I can build my own. I need decent hardware, because I lack knowledge and skills here. Also, its not an interesting stuff to me to play with DSPs and all that stuff really.

Exacly. I've myself been looking around HAMs from networking point of view. I am networker and I would love to get hands on some digital radio.. at least 128Kbps, ideally 1024Kbps stuff where I can slap all the protocol to build network on top of it and then IP. But nope, cannot find anything interesting with decent ranges and cheap enough to buy for tinkering. It seems to be a nische that noone cares to claim.

I know about HSMM, but they are using normal WiFi AP and just slap custom software on top of it and use HAM frequencies. Not bad idea...

They communities are also awfully closed. I tried to find some IRC servers for HAM/network related stuff and no luck really. Found one channel, but they are mostly US people out there (TZ issue for me).

Or you can just run IRC client on start. Just trap SIGINT and SIGTSTP, run simple or modified client that cannot do exec or escape to shell and you are done :)

Well, more retro focused audience.. But also point is, you can do decent webpage that is not bloated and work on older/retro platforms. Its sad what web become, if you do not run latest stuff from FAANG companies, you are pretty much excluded.

No worries, I do NOT feel bad about it. My home page is not for general consumption like smartphone browsers. Im actually very supprised that such a website like Hackers News are being read on smartphones. Damn, world changed a lot.

Pfft.. JavaScript is usefull. Its not my fault that its heavly abused or even generated, turining into bloat. Just take a look at my homepage: http://borg.uu3.net/~borg/

It needs JavaScript, but will work on anything.. from IE 6.0 or FF 2.0 upward. It simple, clean and fast. And imo looks nice :)

Oh comeone people. Answer is simple. Money! Complexity means more money, means spending for developers are justified! Its so complicated after all! Simple solutions that just works will not pay you bills.

VFS = Versioned File System; D means Distributed.

Yeah, im not a big fun of GitHub (especially after Microsoft aquasition), but I also hate that stupid 'we need to grow', 'we need to expand' attitude. Sometimes, tool is done and there is really not much you can improve upon. Especially from UI stand point of view. If you start to force that improvement, usually you end up with over-engineered stuff that starts to be pain to use.

Not always legacy stuff means it bad or should be avoided. Actually, most of the time its kinda other way around. It means its stable and just helps you get the job done. The balance between legacy and progress is not that obvious imo.

And rich people usually do deals off-court. You will pay me this and we are ok. Because its faster and both sides know they capabilities usually.

Uh, hold on. Are we trying to discuss objectivily? If not, and you just insist like GIT is best for everything fanboyism, and use it everywhere.. I am not interested.

I pointed out that GIT have some rough cases and its good to be aware of them. I said it already and will say it again: choose right tool for the task.

If your workflow with GIT works, use it. No need to discourage other solutions. Yes, I use ancient platforms and I want DVFS on them too.

There is several issues depending where you run git on. For example mmap() can be problematic on large files in 32bit OS. On Cygwin it gets even worse.

As for deduplication, I do not think so. If you have single blob, lets say 1GB and you change just 1B, whole blob changes and no more dedup. If you use basic method of static block size, lets say 512KB, this will work much better. Futher, there are more advanced techniques to handle dedups like roling checksums to carve out even smaller sub-block.

Right :) I forgot that everyone is in 64bit systems these days. This change a lot. Anyway, GIT uses single blob for single file content. This is all right, if we speak about source code and text files, as those are not large. Thing changes for arbitrary binary files.

You are wrong.. Just start putting files of GBs in size and you will see what happens.

Ahh, this stuff.. Never done that :) Im happy enough to provide just .rb + ruby.exe (MiniRuby) for Win32. UNIX/Linux is no issue, since can be easly installed or compiled. In worst case I can provide static ruby too there.

Yeah I know about git-annex. It might be good solution for big data. In my case, I do NOT want to decouple storage from metadata. I want single repo for single project that is self-contained. Easier to manage, its truly distributed. No need to bother w/ backups because every replica have everything allready. Its good model for several GBs of data.

Hard to say.. For me DVCS is more advanced version of DVFS. DVCS can do branching and merging, provides more metadata for revisions etc.. DVFS just do pretty much one thing, store binary blobs. And because binary blobs cannot be easly merged, I would not use it for storage here. But I guess, its just me :)

If you do NOT know, then answer that you do NOT know, unless you can speculate. Noone is omniscent. I really dont like when people with no knowledge trying guess the answer or speculate without any background. Im sure I would NOT want to work with such person.

Im not sure what you mean by this... Anyway, if you want to peek at my stuff, take a look at those 2 urls below. One contains various Ruby 1.8.7 Win32 builds (compiled using older Mingw). Other one is my gperf. All this will work on Win2000 and up. In case of gperf, Windows needs to be en_US build. Anything other will simple not work, because Microsoft with they wisdom, localized perf counter names instead aliasing them! Not smart, heh..

http://borg.uu3.net/ftp/pub/archive/ruby/

http://ds-1.ovh.uu3.net/ftp/home/borg/gperf.zip

You are right. GIT is not DVFS, its DVCS. It was made to track source code, not binary data. If you are putting binary to DVCS, you are doing something wrong.

But, there are industries that need it, like game industry. So they should use tool that allow that. I heard that Plastic-SCM is pretty decent at it. Never used it so cant tell personally.

Replacing GIT is such a stupid idea. There is no ONE tool to handle all cases. Just use right one for your workflows. I, for example, have a need to version binary files. I know GIT handles them badly, but I really like the tool. Solution? I wrote my own simple DVFS tool for that usecase: dot.exe (138KB)

Its very simple DVFS for personal use, peer to peer syncing (local, TCP, SSH). Data and Metadata are SHA-1 checksumed. Its pretty speedy for my needs :) After weeks of use use I liked it so much, I added pack storage to handle text files and moved all my notes from SVN to DOT :)

Hmm, I think this is not supported, but probably not very hard to do it at least for Windows (PE executable).

Hard to say about new Ruby versions like 3.x or even 2.x. 1.8.x have pretty simple building process, just grab the old source. You can use --enable-static builds there. Miniruby is build by default, always, because its part of building process.

Also, if you are platform are you targeting? Win32 only?

Yeah.. old ruby have interesting build system. It first build miniruby with is single selfcontained binary having all core ruby functionality. Then, it is used to run some more .rb build scripts to finaly make fully functional ruby.

Actyally that miniruby is pretty usefull. For basic stuff. Also, its very easy to build static ruby containing all extra stuff you care about, like Win32 API for example.

I myself have custom ruby binary on Win32 (Cygwin) with GRX library added in, So I can do basic graph stuff directly from ruby :) That stuff is written in it:

http://borg.uu3.net/~borg/?gperf

Very old one :) Because its reliable. Version 1.8.7 here. I want controllable delays. I want controllable threads :) I want portability.

Of course, if you need more peformance, you need to go for newer stuff.

100ms !!!! wtf? :)

[borg@cube] time ruby -e 'nil'

real 0m0.007s

Well, innovating or start bloating? Usually I see things being overengineered because we MUST innovate. No innovation = going backward.

Progress bar? what for? Is something like that not enough?

Transmiting files: 3/20 (12%), 675kB/s

Or sth like that. Far more informative that just progress bar. And can render anywhere, easly, over 9600bps too.

GUI is more efficient? Joke.. JOKE :) GUI have it uses, for example data presentation and visualization. Oh I have nice tools here too. But data manipulation and query? CLI only or mixed where you query in CLI, got graph output.

But I dont see it as being creative. He is just complaining, not even giving any new ideas.

First, dont like it? Dont use it. No need to cry over it.

Second, dont like it? Write something better, do show case and maybe people like it and start using it.

Third, not everyone needs to use 100s of MB of memory to render some idiotic emoji along the text using GPU accelerated routines. Those old legacy stuff is lightweight, its everywhere so I can run stuff on platforms that problem existed before you were even born.

I myself love CLI. Its reliable, easy to use, fast!! interface. I cant really imagine a computer without CLI.. Its like? WTF? :)

Oh yeah, Carmageddon 1. This game was amazing. I hope they will manage to recreate the engine :) Fingers crossed.

Yeah, I hope it wont happen like this. Unfortunately, Im kinda pesymistic on this one :(