> would probably introduce far more bugs than would be fixed
It runs against the same test suite with no issues
- that proves nothing about bugs existing or not.
857 karma · joined January 17, 2022
It runs against the same test suite with no issues
- that proves nothing about bugs existing or not.
i understand other auth schemes are more complicated, and maybe theres no desire to pull in big libraries. just that if theres no TLS or proper auth, you can also just skip basic auth. its only use would be to trick someone who's not familiar (unlikely with such a repo but not impossible) into a false sense of security.
ofc, not really an issue with the code, and its an excellent base to look into how this stuff works and if you want since its pretty clean and easy to ready, expand upon it. well done! love ppl churning out good ol C projects. respect!
this can be a business model, economic circumstance, mgmt change. a lot can trigger such a shift in services up to then just fine to use.
most companies did not start out on these premises, and its really hard to tell what service will turn next.
i hope maybe ISPs could handle it and offer it as a service. like an ad free internet. but then they will just more deeply embed the ads and it will still get past. changes in designs of the apps will lead to blocking being ineffective.
so really then all that is left is not to use anything that has potential to identify you and your use of it. thats not a lot of things currently. most are frowned upon if you use it in a lot of regions.
Edit: no ok i get u. ensemble learning is a thing ofc. maybe me n other poster reasoned too much from AI == model..but ofc you combine em these days. which is more humanlike guesser levels. (not nearly enough models now ofc)
intel xed is pretty accurate usually but it also doesnt disassemble all possible opcodes.
if you do a jump over some UD but the jmp target is taken from reg value u can also get disassembly to break etc.
its kinda the problem of static analysis. it's not easy to see if someone inserted 1 byte of data, or if it was an unknown opcode u dont handle etc.
definitely fun, will throw off automated tools for analysis especially if you can make the invalid disassembly just call exit or do something valid but short/benign..
may also wanna look if they are known unknown, like this stuff: https://x.com/_markel___/status/1373059797155778562
ive seen now multiple type of either debug or backdoor instructions on x86 based cpus over the past few years
best lesson for me was an HR manager explaining it to me, after finally after 3 years i asked pretty please to give a lil raise, i was still trainee after all that time.
he smiled and said he thought id never ask. made me senior on the department matching my input. and told me this exact fact. He said, why should i give you a raise if you seem happy where ur at? never complain, never ask, never get.
its harsh but its good to understand certain hashness. Then you can work around it, step over that bridge, and be more active in tracking your input, their expectations, and showing them the mismatch deservant of a raise or promotion.
its often peoples shyness or false expectations that get them in such a situation where they feel very under valued. they are because they under value themselves or dont know how to translate/express their value to another persons perspective. another harsh truth. Especially if you are neurodivergent, the way you see things and another is further apart, so your words need to do more to reconcile that difference to generate mutual understanding.
in an ideal world this would not happen or be needed, ofcourse. but we dont live in an ideal world, and there is no switch to flip to make it an ideal world.
A lot of newer things offer different ways to design your code and systems around it, more logical and readable ways.
To give an example: it's not easily discovered your machine just emulates pit/pic via IO-APIC routing to LAPIC :') - its transparent! So if you don't know, and someone told you something else that seems to work, there's no trigger for you to even consider it until you stumble across it by chance.
There are many of these things, especially when in QEMU or such platforms. (how fast does your lapic timer run on qemu vs what the intel docs tell u about its speed?)
it's a lot of fun to do these things, but it's good not to be convinced it's actually how modern OSes work, or modern hardware for that matter.
I’ve always found it curious that most OS dev tutorials still focus on x86_32, even though nearly all CPUs today are 64-bit. It’s probably because older materials are easier to follow, but starting with x86_64 is more relevant and often cleaner.
Yes, 64-bit requires paging from the start, which adds complexity early on. But you can skip the whole 32-bit protected mode setup and jump straight from real mode to long mode, or better yet, use UEFI. UEFI lets you boot directly into a 64-bit context, and it's much easier to work with than BIOS once you get the hang of it. You’ll learn more by writing your own boot code than copying legacy snippets. UEFI support is straightforward, and you can still support BIOS if needed (most old machines are x64 anyway? it's been around for ages now...). Since the ESP partition is FAT32, you can place it early on disk and still leave room for a legacy bootsector if you want dual support. You can even run different payloads depending on the boot method. EDK2 has a learning curve, but once you understand how to resolve protocols and call services, it’s a huge upgrade. Most of it can be written in plain C. I only use a small inline asm trampoline to set up the stack and jump to stage 2. Also, skip legacy stuff like PIC/PIT. They’re emulated now. Use LAPIC for interrupts and timers, and look into MSI/MSI-X for modern interrupt routing. One thing I often see missing in older tutorials is a partition table in the bootsector. Without it, AHCI in QEMU won’t detect your disk atleast on some versions, and this again shows how crumbly and differently implemented some things can be (the ahci nor sata specs require this, so it's a tricky one if it hits you :D...). It’s easy to add, and makes sense if you want multiple partitions. UEFI helps here too—you can build a disk image with real partitions (e.g., FAT32 for boot, ext2/4 for root) and implement them properly. If you don't take into account your system will be using partitions and filesystems within those partitions it's gonna be a lot of re-writing.
Structure of the repo also matters. A clean layout makes it easier to grow your OS without it turning into a mess. This project seems to suggest / imply a nice structure from what I can tell, despite it's also ofcourse modelled around the tutorial itself. - thinking of architecture independence is also often forgotten. Especially when working in newer langauges like Rust that might be apealing ,but most C/C++ code can also be easily made portable if you put foresight into your OS running on different platforms. QEMU can emulate a lot of them for you to test things on.
TL;DR: Most tutorials teach you how to build an OS for 1990s hardware. Fun, but not very useful today. If you want to learn how modern OSes work, start with modern protocols and hardware. Some are more complex, but many are easier to use and better documented which can actually speed up development and reduce the need to port higher level systems over to newer low level code once you decide you want it to run on something less than 20 years old. (Athlon64 was 2003!)
so the BIOS transfers execution to the address. 0x7c00. That is where it also loads your bootsector. After that, your code runs.
For UEFI it's different. And in light of modern PC platforms with things like platform security processors, there's actualyl a lot that happens even before that stage, to verify BIOS and try to aid secure-booting / trusted boot.
try to get other people to value ur time...
other then that id recommend to look into (which will all be in the handbook): emerge, eselect, equery, eix (packages/tools related to package mgr)
also to have it say mean things or send u dont the wrong way on purpose if you ask it lazy questions. :')
the fact there is ppl who do this might both be a source of answers for you and an indication its maybe not a bad idea entirely.
what you hope a technology will become when given away for free, and what it really becomes, thats 2 totally different things.
technology innovators should always be aware of this, and try to align the capabilities of their software to more specific and perhaps restrictive models to protect its users. rather than to give it for free and hope humans will be good with it. especially if there is an angle that will allow a single party to heavily impact its use by investments not available to others..
sorry, i guess when i say leaks i mean a bit more broad stuff :'). my own words are a bit leaky hah
still doesnt mean i am wrong. GC doesnt clean up memory when its released but when it wants to, effectively offering opportunities to get that data after a program dont need it anymore. until some point in time u can usually not specify, just hint at.
that in light of things like bad memory ordering between threads etc..can have nasty bugs... (raii has similar bugs but since its more determenistic you can program your way around lot of it more easily and reliably)
its funny often web basted languages have this property tho , i mean, how else you gonna poison logs and execute them :')... js and php are just adorable for providing opportunities :D