Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "fork you too"
-
Tonight, I had the pleasure of being challenged to make a virus for a VM over at the awesome "virus aquarium": computernewb.com
I present to you the Eevee fork/bomb.
Tonight, was the first night where I've ever sat down and programmed in VBS. I had a lot of fun doing it too. Right now I'm aiming at corrupting taskkill, tskill, and shutdown for good measure. These are a few of the things that my buddy has pulled on me that has made it difficult for me to continue moving forward.
The other part is to create seperate .exe files that would run my the necessary script. Each of these .exe files will be unique such that it's more difficult to shut all of them down at once.
Despite the fact that this thing will quite literally break your computer, it's fun being challenged to think outside of the box. Quite literally. I've always been careful about what things I touched on a PC, but tonight was fun because I was basically unchained and allowed to run rampant.
As a computer geek I think it's good to let out your inner demon and see what havoc one could wreak.11 -
I hate people who just fork my repositories on github without starring it!! if you can go through the trouble of forking a repository why not star it too? :(5
-
Fuck Homestead.
For the fortune of you not to know, Homestead is a sad attempt at a Wix-like build your own website platform.
However, Homestead is the most unusable piece of shit platform that humans have ever had the misery of interacting with
Lets start off with the login page. The login page is small, unresponsive and half the time just deletes your input whenever you press submit.
It's important to note that unless you're running MacOS or Windows, Homestead will send to an error page on which there's a link to contact support, but pressing that link requires MacOS or Windows.
Fine, I'll fiddle around with my user-agent, and we'll be in soon enough. But now we come to the joy that is the website editor itself.
The website editor is clunky, hard to use, and has enough menus and submenus and sidebars to make the Jira UI shake with fear. Each interface option label is either ridiculously ambiguous or just straight up wrong. The built-in HTML editor doesn't support HTML5, in the name of "browser compatibility".
CSS? Pah! Who needs it! Our psuedo-90s skeuomorphic ugly-as-shit prebuilt styles will work just fine. Responsive design? Bullshit! Nobody uses a smartphone to browse the web, so why do we need to handle it?
Uploading a file? Good fucking luck buddy. There's a complicated dance among the minefield of pop-ups that ask you to confirm some shit or modify some shit and you gotta click the right option each time or else the file won't upload.
Wanna use https like 86% of the entire web and all modern websites? That's a premium feature. Fork over an extra $10 a month
Ok ok, I made it through all that. Dig through the thousands of menus to find the 'publish changes' button, and sigh with relief.
Open up a private browser tab to check my work, and nope. The site looks like shit, even by Homestead's standards. That's because Homestead claims to be a WYSIWYG editor, but it's a damn lie. The site looks like shit, so it's time do dive back into the hellhole that is this damn site editor.
And rinse and repeat. Deal with the shitty editor, publish, and pray it doesn't look like garbage. Be too scared to test on other devices because this flaming pile of dog shit pretending to be a website is bad enough on my device.
Two more months, then I'm done with this client. Someone get me a drink4 -
Github 101 (many of these things pertain to other places, but Github is what I'll focus on)
- Even the best still get their shit closed - PRs, issues, whatever. It's a part of the process; learn from it and move on.
- Not every maintainer is nice. Not every maintainer wants X feature. Not every maintainer will give you the time of day. You will never change this, so don't take it personally.
- Asking questions is okay. The trackers aren't just for bug reports/feature requests/PRs. Some maintainers will point you toward StackOverflow but that's usually code for "I don't have time to help you", not "you did something wrong".
- If you open an issue (or ask a question) and it receives a response and then it's closed, don't be upset - that's just how that works. An open issue means something actionable can still happen. If your question has been answered or issue has been resolved, the issue being closed helps maintainers keep things un-cluttered. It's not a middle finger to the face.
- Further, on especially noisy or popular repositories, locking the issue might happen when it's closed. Again, while it might feel like it, it's not a middle finger. It just prevents certain types of wrongdoing from the less... courteous or common-sense-having users.
- Never assume anything about who you're talking to, ever. Even recently, I made this mistake when correcting someone about calling what I thought was "powerpc" just "power". I told them "hey, it's called powerpc by the way" and they (kindly) let me know it's "power" and why, and also that they're on the Power team. Needless to say, they had the authority in that situation. Some people aren't as nice, but the best way to avoid heated discussion is....
- ... don't assume malice. Often I've come across what I perceived to be a rude or pushy comment. Sometimes, it feels as though the person is demanding something. As a native English speaker, I naturally tried to read between the lines as English speakers love to tuck away hidden meanings and emotions into finely crafted sentences. However, in many cases, it turns out that the other person didn't speak English well enough at all and that the easiest and most accurate way for them to convey something was bluntly and directly in English (since, of course, that's the easiest way). Cultures differ, priorities differ, patience tolerances differ. We're all people after all - so don't assume someone is being mean or is trying to start a fight. Insinuating such might actually make things worse.
- Please, PLEASE, search issues first before you open a new one. Explaining why one of my packages will not be re-written as an ESM module is almost muscle memory at this point.
- If you put in the effort, so will I (as a maintainer). Oftentimes, when you're opening an issue on a repository, the owner hasn't looked at the code in a while. If you give them a lot of hints as to how to solve a problem or answer your question, you're going to make them super, duper happy. Provide stack traces, reproduction cases, links to the source code - even open a PR if you can. I can respond to issues and approve PRs from anywhere, but can't always investigate an issue on a computer as readily. This is especially true when filing bugs - if you don't help me solve it, it simply won't be solved.
- [warning: controversial] Emojis dillute your content. It's not often I see it, but sometimes I see someone use emojis every few words to "accent" the word before it. It's annoying, counterproductive, and makes you look like an idiot. It also makes me want to help you way less.
- Github's code search is awful. If you're really looking for something, clone (--depth=1) the repository into /tmp or something and [rip]grep it yourself. Believe me, it will save you time looking for things that clearly exist but don't show up in the search results (or is buried behind an ocean of test files).
- Thanking a maintainer goes a very long way in making connections, especially when you're interacting somewhat heavily with a repository. It almost never happens and having talked with several very famous OSSers about this in the past it really makes our week when it happens. If you ever feel as though you're being noisy or anxious about interacting with a repository, remember that ending your comment with a quick "btw thanks for a cool repo, it's really helpful" always sets things off on a Good Note.
- If you open an issue or a PR, don't close it if it doesn't receive attention. It's really annoying, causes ambiguity in licensing, and doesn't solve anything. It also makes you look overdramatic. OSS is by and large supported by peoples' free time. Life gets in the way a LOT, especially right now, so it's not unusual for an issue (or even a PR) to go untouched for a few weeks, months, or (in some cases) a year or so. If it's urgent, fork :)
I'll leave it at that. I hear about a lot of people too anxious to contribute or interact on Github, but it really isn't so bad!4 -
Avoid ACPICA if at all possible. It's one garbage tier cluster fuck of bad design, horrible documentation and downright misleading and wrong code
It's meant to consist of an ASL compiler, disassembler, debugger, dumper, various user space utitilies and a kernel resident OSPM implementation *if* you can figure out what belongs to what. Even just compiling this pile of trash is a mystery in itself. Think you need the source files in source/common? EEEEH, wrong. Well, at least partially since most of them seem to be for the user space stuff..? Other ones *are* needed on the other hand. At least the disassembler and/or debugger and/or dumper components seem to reference them. Not that I could figure out how to compile those anyways. The real path to your goal seems to be to ignore a seemingly arbitrary subset of source and header files until your linker stops complaining
There's also a bunch of configuration defines, some of which *you* define, some defined *for* you, based on again others. Of course most of them do stupid shit. Enabling the debugger automatically enables debug logging. Enabling the disassembler force enables debug allocation tracking... What?
The code itself isn't of much help either. Looking in "os_specific/service_layers" you find what looks to be reference implementations of acpica functions in certain os' like windows and unix. Of course I had a look because AcpiOsReadMemory is supposed to read physical memory and I don't know how I would even implement that. But hey, osunixxf.c (xf for interface... of course) should tell me. I'll let you see for yourself in the attached image. Apparently it does fuck all and just returns AE_OK. No error, no logging, no nothing. Just ok. As you can imagine, AcpiOsWriteMemory doesn't do much more either.
...okay so maybe physical memory accesses aren't actually used and these functions are some sort of relic from past times? Nope! They are absolutely necessary for doing low level device interaction. WTF. So finally I went to the linux source and checked how *they* implemented them, and just as I thought, these functions are anything but no-ops...
...So for what fucking reason do these stupid interface implementations even exist but to purposefully mislead you?? They aren't used for fucking anything! As far as I know Windows doesn't even *use* ACPICA and Linux have their own fork with working implementations... They just sit there, just to tell you how to NOT do it
So that's some of my thoughts about ACPICA. Note that I haven't even used it as a library yet, I just got it to compile and link and it already fucked with me this much.
There's also so much more I didn't mention like that you *have* to modify the acpica source in order to get your own platform header working (else #error) eventhough the docs explicitely instruct you not too but you get the point
Don't use ACPICA if you don't have to. Save your sanity for something that's worth it -
So once again if you want to buy a Google branded Chromebook and you aren't in the centre of the universe that is America you're shit out of luck...
To get last year's pixelbook that is $999 US in Australia I have to fork out $3000, no word on importing the pixel slate but as always America is the greatest, you get everything and everywhere else can get fucked I guess....
Why can't tech companies just realise that other countries want things too?!5 -
OpenSource is fun they said. I being a bored teen thought, ah, another chance to experiment. Discover something new. Now I am into piracy, movies, music, software. If I can get it for free I ain't paying for it. So I went on to GitHub to see what exciting new Repos I could contribute to. I hate already implemented plenty of algorithms in GO for GitHub.com/TheAlgorithms so I was looking something more practical, more beneficial to society. Then I saw it, the perfect repo, not too complex and not amateur. SpotDL/spotify-downloader for downloading songs from Spotify, a grey area coz it's technically piracy. Well not from Spotify, we fetch the info from the Spotify API and search for the songs on YouTubeMusic. They were just about to release v3, a complete rewrite of the codebase stressing code readability and stuff. I spend about a day studying the codebase, trying to findout just where I could make my contribution. I can see outright that there's a huge problem with implementation.
First of all the script spawns 4 processes for downloading songs though you might be downloading only one song. Which means for everytime you run the script you have to wait for 4 other processes to be spawned before any downloading can happen. Sure this is faster when you are downloading more than like 4 songs, but it's actually slower when downloading a single song. But I ignored that coz I assumed that most users download playlists and albums. Anyway we talked with the like lead developer and he was all like, make those PRs anytime you feel like. So I made a really minor first contribution.
I introduced download from Spotify URI functionality, modified like 10 lines of code. I was half expecting that the PR would be merged within hours at most 24 hours coz of how minor of a contribution it was, 5 days in it was pending. So I tagged the lead Dev and he was all appreciative of the PR, calling it real 'clean code' and stuff. 3 more days, the PR is still not merged. I have now stacked 4 more commits to the same PR, I tag the dev and he's like he's waiting to see if my 'feature' will get atleast 10 upvotes so that it can be merged, he links an issue. I go to the issue and my feature is not there, So 11 days after I made my PR I have to write a comment explaining the 'feature' introduced in my PR and then wait for 10 upvotes.
I was like f**k this, I'll just develop on my fork if you want the features on my fork, you will make your own PR! I am so done with OpenSource, development is slow. I have no idea how you guys do it. I can't handle development where I don't have write access.6