HN user
Tomasz (of fasmg) added "one more quick thought" re: 8-bit word not being a limitation, he said that since fasm1 had macros for LZW compression [0] (from the assembler alone) and that this is even easier with fasmg the word length isn't a restricting factor with his design either. Cheers and thanks for sharing.
I reached out to the author of fasmg WRT your post and circular dependency interest and he pointed me toward two posts that he wrote very specifically to explain what he believes is unique to fasm/fasmg and allows to handle circular dependencies of many kinds. [0] Types of multi-pass assembly, and [1] related pitfalls.
Very cool and I like the idea of a "meta-assembler." The most-recent version of flatassembler (fasm 2) is built with fasmg which is also a "meta-assembler" of sorts, in that it also doesn't directly support a specific instruction set and instead is a very powerful macro assembler. I'm keen to check out functionality overlaps between the two implementations.
One of the things that actually sold me aside from the repairability thing and all was their wikipedia page[0] where it says that "HMD is headquartered in Espoo, Finland, and is largely run by former Nokia executives."
I was rather hoping that it'd be more like the Nokia we all remember from pre-iPhones. Guess not.
Bought it online directly from Nokia, though it came from their partner Ingram Micro.
A couple of years ago I did a "Terminal Video Series" segment that also highlights the runtime overhead of 12 other languages, C of course actually one of the best ones: https://2ton.com.au/videos/tvs_part1/
I routinely don't want persistent mount points. Imagine my: cryptsetup luksOpen /dev/sdXY name Followed by: mkdir -pv /dev/shm/name mount -o noatime /dev/mapper/name /dev/shm/name
What this "RemoveIPC" did for me was rm -rf all of that, even if I mounted them as root.
That a single "RemoveIPC" difference between openSUSE 15.2 and 15.3, undocumented, caused me to lose all that data is one thing.
Another thing entirely to question WHY "RemoveIPC" is even a thing to begin with. I have never logged into any machine and said "wow look at all of this stale data taking up RAM in /dev/shm".
In fairness, that history seems to indicate that maybe it really was SUSE who decided to enable it. Sure seems like "RemoveIPC" option should have been advertised as a 15.2 -> 15.3 update repercussion. :-( :-( Leap 15.2 didn't do that, 15.3 does. Unknown what the other systemd distros do with "POSIX shared memory cleanup"
Flat Assembler is actually easier to get your head around early on than any of the *asm variants IMO: https://flatassembler.net/
I also learned Z80 first, and I can say categorically that learning 16-bit x86 is NOT a good idea. To do anything useful in 16-bit, register starvation is a constant. Segmentation issues are actually hard problems.
I submit that if x64 existed early-on, no one would have bothered with higher-level abstractions. x64 is actually -pleasant- to code in natively.
I wrote a Linux general purpose library for x64 assembler: https://2ton.com.au/HeavyThing/ and in recent months I decided to start doing video tutorials about the "how and why" of same. Learning I think is made easiest in Linux by learning how to navigate the syscall interface and how "man 2 write" becomes an important skill. Edit: Videos link as well: https://2ton.com.au/videos/
Obligatory addition of the assembly language TetrOS in a single boot sector (512 bytes) from the author of flat assembler many years ago
probably should have titled it "now" instead of 09:00 UTC, apologies.
Definitely not banned, sshtalk kakked itself under the HN glow (that and I left it open in a terminal window here and had an insane number of tiled chats open, might have a bug in there too)
This is a sad statement. Proficiency in a given language/environment dictates how long and painful a solution will be. Use cases for this are no different to any computing-related task, though I concede it isn't for everyone :-) Neither is Python, Perl, Java, JS, Node, and hey, lets throw in COBOL because you know, there was never a use case for that either. /sarcasm
fasm was in fact modelled after early TASM, and much of the "high level constructs" are just macros... or did you mean something more specific?
Start simple and hook fasm in with a "normal" gcc/g++ project... I wrote a page[0] ages ago on integrating C/C++ with the HeavyThing library and a good portion of that has nothing to do with my library specifically and is a great starting point to mess around with assembler on a Linux platform. The only other pointer is the "call PLT" format for calling externally linked functions from inside your fasm objects but that is the only tricky bit IMO.
The IDE is indeed written entirely in assembly language, as is everything from the webserver up (JohnFound, author of FreshLib/FreshIDE also wrote a fastcgi layer to interconnect with rwasa from my own goods). Everything there is assembler.
Hahah, proper Aussie mate! (there's a compile-time flag to make them all boring instead of our homage to Aussie slang haha, cheers and glad you like it)
Compelled to chime in here and say that you can just as easily write bad HLL that the compiler can't do much with in the first place.
Also back in 2016, I participated in a pseudo-challenge on the fasm board [1] and it is trivial to optimise both the C/C++ as well as hand-written assembly. IMO comparing how good a compiler is at optimising is akin to how good it is at figuring out your intentions (and they all suck at that).
Greetings again to all HNers,
This was up here ages ago, I still use it personally but for some reason it has gotten renewed attention today from a random post to 4ch/reddit. Happy to see some people still dig my x86_64 assembler work :-) Cheers!
when I wrote hnwatch last year, there were some "issues" with the firebase feed, but for the most part the firebaseio goods are in fact realtime.
Mosh has this fully sorted too IMO: https://mosh.mit.edu
Only fixed wireless where I am on the Sunshine Coast, QLD .. and unfortunately my building is not line of sight to the tower, so I don't have any options whatsoever. ~2mbps/200kbps on a good day, otherwise the backhaul is so saturated it is practically unusable. :-( I can get satellite apparently, but last I checked they hadn't worked out the physics to get terminal lag/latencies down to acceptable levels for that to be an actually viable alternative. At least where I am, the NBN is a joke even for those that do have it.
Bit late to the party here, but this is why I wrote https://2ton.com.au/dhtool/ ... I have 48 CPU cores still dedicated to constantly generating safe primes and generators (have amassed a huge number of 2k, 3k, 4k and 8k DH parameters if anyone's interested)
Any of the sizes' most recent 128 parameters can be downloaded in SSH moduli format, e.g. https://2ton.com.au/dhparam/4096/ssh
Impressive amount of effort here. How is this different/better than using a strong static encryption for data and then using "normal" redundant cloud storage services like backblaze? Also, why did you choose Nettle's pbkdf2_hmac_sha256 for key derivation, and how does a user-supplied password end up mixed with server generated ones? (or am I confused altogether?)
On my list of things to do is to write an article titled "VDSO and why you should care." Interestingly, syscall indirection isn't among my reasons (maybe I am too comfortable in my SSE2+ x86_64 environment). If anyone is interested, the magic all lives in /proc/self/auxv, and my own library implementation to hook gettimeofday can be perused at:
This is a beauty, thanks for sharing! I second the recommendation.
IMO, bootloader/video memory is quite a distance from the traditional model of what "Hello World" is meant to be about, no? If anyone's interested, there are lots of very simple bootloader Hello World goods around:
By default all code/RIP addresses are <32 bit, no harm no foul.