Details
-
AboutGeneralist.
Joined devRant on 11/4/2020
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
-
@kamen No full source available, a dealbreaker for me.
-
@kiki I'll disagree. Jailbreaking isn't always possible, and you have just one manufacturer making these devices. The manufacturer puts active effort into mitigating the ways to jailbreak. On the contrary, OnePlus devices (and some others) explicitly allow to swap the ROM and do whatever you want with the device in terms of software customization without even voiding a warranty. With some other blokes (Samsung and the whole normie device niche) you'll get your warranty voided but it's still possible. Some manufacturers will actively resist but you've got a physical access and there's no secureboot checks to verify that you didn't slap on your own ROM, doable but pain in the ass.
On the topic of why having an Android is marginally better compared to jailbreak iWhatever: Linux kernel. You'll be able to kill off the zygote, chroot into some env you've set up and run X, effectively making it a desktop device if needed. Pretty damn slick if you ask me. -
@Root There's more: the burning trash pile has a tendency to taint the good parts over time, so this neat and tidy part you've brought in will morph into trash to join the rest of the pack.
-
@Hazarth The point about it not appearing overwhelming for a newbie is valid. Though I'd still hold my ground just a bit by saying that some types of people are more effective when they have the full picture. After all, the journey is sometimes more about the joy of milestones that we hit along the way, right?
-
@Hazarth Kinda needs further steps right in the list instead of vague notion of "going deeper". If the language is based on some VM, it's imperative to learn its inner workings. If you target a particular compiler, you're better off knowing its pros and cons, some of its bugs even. Being familiar with the majority of standard library is also a minimum you're going to need in a day-to-day practice. Just hacking together some simple stuff just isn't enough to "learn" a language. Sure, you feel comfortable using some basic parts of the tool but you still don't *know* it.
-
Wonder why no one mentioned SourceMaking. Pretty fun and accessible if you're just interested in abstractions.
-
Chromium, if you still need the engine to be there. Otherwise it depends on what you want from your browser. You can go GNU IceCat if you're privacy-pilled, you can go Firefox if less. There are also Webkit based ones like, say, Qute, though Qute is targeted more towards the demographic that loves vi-like keybindings.
-
Hello here, Mr. @Godisalie, we're here to talk about your NDA...
-
Hoodies are pretty rare in my workplace as well. Maybe under a single percent even.
-
@hjk101 I have nothing against using technologies for tasks they were designed to solve, don't get me wrong. It's just that tools often get misused, and it goes completely under the radar, creating atrocities marketed as finished products.
-
@kiki At least they kinda allow you to have a root on your own damn device, so you don't need to feel like you rent it.
-
Just use FOSS, turn yourself into a message instead of being a product. These proprietary operating systems are garbage anyway.
-
They sadly also suck for consumers (as you've pointed out in this rant). It appears like these are just like regular outsource body shops but on heavy steroids. I'm currently working with a company that has something like a division of it in India (basically they've hired or bought a company there to do a noticeable chunk of stuff, idk), and Jesus, it's a dumpster fire.
I'm not trying to call names here but it appears like they don't vet their employees (talking management as well) whatsoever. You may routinely end up helping out a "senior" engineer to do the most basic stuff imaginable, and you have to basically gatekeep the project repo to avoid dealing with them introducing a bug or unnecessary complexity by what they conjure up. Frankly, doesn't save money, since you're compensating this crap with your time anyway.
Anyway, godspeed to you. Save up some cash and migrate outta there for better opportunities. -
@junon On Windows comment: doesn't it run on mingw? Am I missing something? I mean, you have a bunch of coreutils on it as well, and you don't really need a full compliance to *just run compilers with it*.
-
The whole "oh but muh feels" thing is a huge topic by itself. I'm contemplating completely moving to BSDs just because these chumps are actually successful in their attempts to use big FOSS as a political tool. There's even a bunch of tech giants who back this, and nowadays even software development isn't about the quality anymore. It's about being polite towards complete morons for no reason other than them crying out real loud about the fact that someone doesn't like the agenda and the technical decisions they attempt to push. Just do stuff right.
Back then, Antirez bought into this crap. Now it's more than just him, it came to huge project maintainers who for some reason stop to listen to this bullshit. -
@junon WDYM Bash is not portable? You can pretty reliably do builds in Bash on pretty much anything that can run it. By this, I mean *any* system that you'd build your stuff on. And there isn't a meaningful performance margin in between C build tools, since the majority of the time is spend running your compiler, Bash will just be a means to launch it with appropriate flags, etc., so theoretically, if you're not satisfied with Make, you can do a bit more in Bash instead.
-
@Hazarth Depends on your definition of sysadmin stuff actually.
-
@N00bPancakes 'man' knows how to do things right, alright? That why it's called so!
Seriously though, man and grep aren't enough of course. It's just that they do things WAY too easy even when you have no clue. There's a lot more to writing something well, from the knowledge of lower-level quirks of the tech in question and to subtle style-related decisions (as in "I wrote this line this way because..."). The latter ones are arguably the most important part of making your stuff maintainable and understandable.
That said, I usually don't even remember the codebase layout and what does what, especially if it's a huge project. I just grep my way to victory. Sometimes you can grep your way to the cause of some obscure bug, no debugger, no profiling, no "what if" runs or recompilation, just by going for an educated guess and grepping around. -
Y u got beef with my very own completely hand-wired custom split keyboard though? :(
I'm *very* angery now...
Nevertheless, I agree with the message. -
If you're positive it worked a week ago on a same setup, file a bug.
-
@junon Bash it is, then!
-
I once killed a whole drive early in my career, and did it way faster. Static isn't a joke, lads.
-
Forgot to add this: try to avoid outsource bodyshops. These will make you suffer and they generally offer lower paychecks while treating you like crap.
-
Frankly I'd have a stroke upon realizing that the base is bloated. Even if I need the tool in question. It's just a sign that there might be things I don't really need.
-
Market your skills instead of just agreeing with what you're offered. Go set a high price tag on your resume right now and mass send it off to the companies you think you'd want to notice you. Not to the one you actually desperately want to end up in. Try to go for an interview, discuss more than just hard skills (soft skills matter a lot if not more than hard ones), take note of what you fail to answer to.
Note: price tag matters. The lower tags can deter the big companies from actually hiring you because your self-evaluation makes a difference as well.
As of resumes, try to keep them short and on topic. Don't spam the auxiliary stuff, you won't need it, and the employer doesn't care about it. Additional topics may also become your pain points, leading interviewers into prying hard on them because they happen to be their hobbies, so even if you're insanely generalist about your stack, just don't. Hope that helps. -
Schooling does nothing when it comes to learning (hate the word but it fits, so...) LITERALLY anything related to software development. It might give you some basic things but you're quite frankly better off doing it on your own. A food for thought: why do you think they're stuck "teaching" you instead of making actual money out in the wild? Just go get some decent books related to your topic and grind them until you're qualified enough to pass an internship or whatever. You won't learn anything you really need to do your job well in school/college, don't waste your time.
-
Just use GNU Make.
-
Generate it.
/thread -
@EdoPhoenix I can agree on a somewhat faster delivery time. Could still argue though, I'm a first-hand witness of the modern JS ecosystem's complexity and have seen lots of completely redundant rituals surrounding the apps. People often plan on doing a larger-scale application, which leads to their projects having a lot of bloat they would've avoided with a better planning.
The problem is, large companies do it. Look at MS Teams or VSCode, for instance. Look at Slack. Look at Discord It's not like they're short on resources to make a faster and lighter version for the app in question. It's just they don't ever come around to do it while the initial trajectory likely treated an Electron thing as an MVP that was to be replaced once the hypothesis is tested (Slack/Discord for sure belong to this category). Mind you, there's an alternative implementation of Discord in GTK, and it's completely open-source, made by eight devs or so. -
@RememberMe Qt is cross-platform, for instance. And lots of similar solutions are cross-platform, too. You still need to have a matching compiler but that's absolutely not a problem.
As of memory, T480s that I use for hobby projects (as in "no Slacks, no JIRAs" is completely fine, 16 GB are MASSIVE when you don't really run much) holds up OK. Workstation is barely breathing on a nice sunny day with a couple fancy-looking docs open, with the local infrastructure (not a lot, 5GB or so), and JIRAs, Slacks, fancy webpages and such usually build up to eat around 20 to 25GB and more, choking the available space for maneuvers down to 1GB or so. Stuff swaps in, swaps out, 1GB that's left is used for a compiler to do its job, and sometimes an evil OOM killer shoots at tabs.
>beef with Docker
Overused, often unnecessary, lacks maturity but somehow dominates stuff. Also leads to your coworkers bringing in some phat images that will cost you a lot of diskspace eventually.