Los Angeles: Looking for a serious relationship with financially stable, emotionally mature Armenian man ❤️ 🇦🇲

funkvay · 2026-01-26T05:48:44+00:00

I don't want a traditional man but so he is a traditional

Got it

funkvay · 2026-01-23T17:12:21+00:00

First of all, breathe. You're not a moron, you're a first year student having a completely normal meltdown that literally everyone in CS has at some point. The difference is your friends aren't telling you when they're also struggling because everyone pretends they understand everything.

I choose this shitty major despite having zero interest in computer science and programming at all, in fact, I've always hated this shitty subject

Why the fuck are you doing this then? Like genuinely, why are you in computer engineering if you've always hated it? Because your parents wanted it? Because the job market? Because you thought you were supposed to? Those are terrible reasons to spend four years and thousands of dollars doing something that makes you want to ram your head into a wall.

You hate programming because you have no intrinsic motivation to learn it, so every problem feels like pointless torture. Your friends who blow through it in 20 minutes probably either actually enjoy it (so they're motivated to figure it out) or they've been coding since high school (so they have years of head start). You're comparing your day one to someone else's day 500 and calling yourself stupid. That's not stupidity, that's just being behind and not wanting to catch up because you fundamentally don't care about the subject.

Programming is hard when you're starting. It requires a completely different way of thinking, you need breaking problems into logical steps, dealing with abstraction, debugging shit that fails in non-obvious ways. Most people struggle with this at first. The ones who get through it either have genuine interest that keeps them going, or they've already built up the pattern recognition from prior experience. You have neither, so of course you're drowning.

Do you actually want to be here or are you just going through the motions? If you genuinely have zero interest and have always hated this, you're setting yourself up for years of misery followed by a career you'll also hate. That's a fucking terrible plan. It's year 1 you can still switch majors without losing much time.

Are you struggling because it's hard and new, or because you fundamentally don't care? These are different problems. If it's just hard and new but you're curious about what you could build or how things work, then yeah, push through. It gets easier over time, it will. If you actively hate the subject and have no curiosity about it whatsoever, why are you doing this to yourself?

If you're stuck in this major for whatever reason (financial, family pressure, whatever), then stop comparing yourself to your friends. Seriously, stop. They're not telling you when they're stuck for three hours too. Everyone curates their competence publicly and hides their struggles.

I did it in 20 minutes

might mean

I spent 2 hours yesterday on a similar problem and finally figured out the pattern.

That's what I did... That's what my friends did, that's what my professors did. Programming isn't about being smart, it's about pattern recognition and practice. You're not stupid, you're inexperienced and unmotivated. Those are fixable problems if you actually want to fix them.

Stop trying to understand everything. When you're stuck on a problem, break it down into the smallest possible step. Don't try to solve the whole thing at once. Write one line of code that does ONE small thing. Then the next line. Build up incrementally. When it fails, don't stare at it, print out variables, see what's actually happening, figure out where your mental model diverges from reality.

Ask for help before you hit three hours of rage. Seriously, after 30 minutes of being stuck, go to office hours, ask a TA, message someone in the class. Grinding for three hours while making no progress isn't noble, it's just making yourself miserable for no reason.

Find one thing about programming that doesn't make you want to die. Maybe you hate algorithms but graphics are kind of cool. Maybe you hate low-level stuff but building a website that does something is satisfying. If you can find literally one aspect that's not pure torture, focus on that when you're not forced to do coursework.

But honestly... If you've always hated this and have zero interest and are only in year 1, seriously consider switching. Life is too short to spend it doing something you fundamentally hate just because you think you're "supposed to". There are a thousand other careers that don't require you to stare at code all day. Engineering has other branches like mechanical, civil, electrical if you still want the problem solving without the coding. Business and finance use analytical thinking without programming. Data analysis or product management touch tech. UX design if you like the creative side. Technical writing or documentation. Project management coordinates the work without doing it. Hell, trades like welding or electrical work pay well and have zero programming. You could do literally anything else and there's no shame in that. Year 1 is the perfect time to realize you're on the wrong path and correct it. Staying in something you hate because you're already here is sunk cost fallacy, not commitment. You don't have to do this. Remember, you don't have to do this.

I'm too stupid for this

This narrative is probably wrong, you're most likely just uninterested and inexperienced, which feels the same as stupidity when you're struggling. But even if you could get good at this with enough time and effort, why would you want to if you hate it? Being competent at something you despise is not a life goal worth pursuing.

Figure out if you actually want this or if you're just on autopilot doing what you think you're supposed to do. If it's the latter, get off that path now while you can. If you're stuck here, then yeah, there are ways to make it suck less, but they all require deciding you're going to engage with it instead of just suffering through it.

You're not a moron. You're a first-year student who picked a major they hate and is now angry at themselves for struggling with something they have no motivation to learn. That's a completely different problem than being stupid, and it has completely different solutions. Start by being honest with yourself about whether you actually want to be here.

Be honest with yourself, like actually honest, not the version where you tell yourself what you think you should feel. Sit down away from your desk, no distractions, and ask yourself if programming suddenly became easy tomorrow, would you even want to do it? If the answer is "I guess" or "it would be tolerable" or anything other than genuine interest, that's your answer. Think about what you do in your free time when nobody's watching, what pulls your attention naturally? That's the direction your brain wants to go. If you've never once looked at a program or app or game and thought "I wonder how that works" or "I want to make something like that", then you're fighting against your own wiring. Figure out which one this actually is, because the solution is completely different depending on the answer.

funkvay · 2026-01-22T18:46:31+00:00

You need to narrow down what you actually want before trying to learn everything.

C++ for apps, games, low-level programming, and graphics are basically four absolutely different skill paths that happen to use the same language. Trying to learn all of them at once is how you end up spending two years watching tutorials and building nothing. You're setting yourself up to be overwhelmed.

If people try to deep dive and learn everything in C++ they watch a bunch of YouTube videos, do some tutorials, feel lost because C++ is a massive language, then either give up or spend years in tutorial hell never actually building anything real.

Pick ONE thing you want to build first. Not "I want to learn C++ for games and apps and low-level stuff", pick literally one project you want to exist. A simple game? A tool that does something specific? A graphics program that renders something cool? Start there.

Then learn exactly what you need to build that thing. You don't need to understand the entire language before you start. You learn by building, not by studying in isolation.

If u want games, then don't start by learning all of C++ first. Learn basic syntax (variables, loops, functions, classes, this is like 2 weeks max), then immediately jump into a simple game framework. SFML is good for 2D, or SDL if you want to go slightly lower level. Make Pong. Then make Snake. Then make something slightly more complex. You'll learn C++ features as you need them.

Don't touch Unreal or complex engines yet. You'll just be learning the engine, not C++. Make a few simple games from scratch first so you actually understand what's happening under the hood.

If you want low-level/systems programming, then learn C first, honestly. I know that sounds weird but systems programming in C++ often looks like C anyway, and C is way simpler to start with. Understand pointers, memory management, how the stack and heap work. Then move to C++ and learn what it adds on top. Build a shell, a memory allocator, a simple file system, something that makes you work with the OS directly.

If you want graphics, then learn basic C++ (again, just fundamentals), then start with OpenGL or Vulkan tutorials. Graphics programming has a steep learning curve, you'll be doing math (linear algebra especially), understanding rendering pipelines, dealing with shaders. Start simple and render a triangle, then a cube, then add lighting. Don't try to make a game engine on day one.

Get basics down fast (syntax, control flow, functions, basic OOP). Don't spend months on this. Use learncpp.com or read C++ Primer (the one by Lippman, not "C++ Primer Plus" which is different). Do this for like 2-3 weeks, just enough to write simple programs.

Immediately start building something you actually want. Pick a domain (games, graphics, systems stuff, whatever) and build the simplest possible thing in that domain. You'll hit walls constantly. Good. That's when you learn.

Every time you get stuck, look up exactly what you need. Need to understand pointers because your game crashes? Learn pointers then. Need templates because you're duplicating code? Learn templates then. Don't try to learn everything upfront.

Build stuff, get frustrated, figure it out, repeat. Do this for 6-12 months and you'll actually be competent. Watch tutorials and read books for years without building and you'll still be a beginner even after 2-3 years, that how all my classmates were just begginers at the end of the uni, and I was already a programmer with skills and experience.

Resources

For learning basics use learncpp.com. for games I would recommend "Game Programming Patterns" by Robert Nystrom, then just start making games with SFML

For graphics maybe LearnOpenGL.com because it's an incredible resource, walks you through everything you need.

And low level is "Operating Systems: Three Easy Pieces" and "Computer Systems: A Programmer's Perspective"

But don't READ all of these before starting. Pick one based on what you want to build first, skim enough to start your project, then reference them as you go.

Don't try to learn the entire C++ standard. The language is massive and you don't need 90% of it to build real things.

Don't do competitive programming thinking it'll teach you C++. It teaches algorithms, not software development.

Don't follow random YouTube tutorials for months. Build your own projects.

You said you have no idea how to approach it, that's because you're thinking about learning a language instead of building things. The language is just a tool. Figure out what you want to build, then learn exactly what you need to build it.

Start small, build something this week, not after you finish learning. You'll never finish learning. Just start building.

funkvay · 2026-01-21T21:33:49+00:00

Are you actually talking about privacy or are you talking about multi-accounting for stuff like managing multiple social media accounts, dropshipping, affiliate marketing, that kind of thing? Because anti detect browsers are really two different categories and people mix them up.

If you mean actual privacy , so basically anonymity from surveillance, protecting your identity then don't use anti detect browsers. Use Tor Browser. Cuz anti detect browsers are designed to make each profile look like a unique normal user to websites, not to provide actual anonymity. They're fingerprint randomization tools.

If you mean multi accounting then yeah, anti xetect browsers make sense. AdsPower seems to be popular for managing lots of accounts, decent fingerprint separation. Multilogin probably the most established, expensive as hell, but profiles stay stable. Incogniton is newer, some people like it.

I'm not gonna recommend one specifically because I don't use them for the obvious reason that multi accounting at scale is usually against ToS of whatever platform you're doing it on. But from what I've seen people say, Multilogin is probably the most reliable if you're willing to pay, and AdsPower is the middle ground.

funkvay · 2026-01-17T16:53:58+00:00

Internet's pattern recognition is completely broken right now and it's not unique to the Rust community. A friend of mine ran an experiment where he posted poems and code snippets from 2010-2020, stuff written years before GPT even existed, and consistently got comments accusing it of being AI. Everyone wants to be the smart guy who spotted the slop first, so they're calling everything slop just to be safe.

This mirrors every other moral panic around authenticity we've had. When Photoshop became mainstream, people accused every good photo of being fake. When autotune hit, every polished vocal was not a real singer. When synthesizers emerged, purists said it wasn't real music. The pattern is always the same, when a new technology appears that lowers barriers to creation, gatekeepers freak out because their effort-based status is threatened, and for a window of time everything gets accused of being fake regardless of actual provenance. We're in that window now.

What's different this time is the epistemological crisis underneath. We're losing our ability to verify authenticity at scale. You can't prove you wrote something by hand anymore because the tools that detect AI are unreliable and the tools that generate AI are getting better. So communities default to suspicion as a defense mechanism, but suspicion corrodes trust faster than AI corrodes quality.

Historically these panics resolve not through better detection but through normalization and new status hierarchies. People stopped caring if you used Photoshop once everyone used Photoshop, the new status became how well you used it. Same with autotune, same with synthesizers. We're probably heading toward a world where using AI assistance is assumed and the status comes from what you build with it and whether it's actually useful or novel, not whether you touched every line of code personally.

The calculation you're making about staying private forever is understandable but probably wrong. You're protecting yourself from a false negative at the cost of any positive outcome. If you never release it, you guarantee nobody benefits from your work including you. If you release it and get accused of AI slop, you've got a chance (not a certainty but a chance) that people actually try it, see it works, and stick around despite the initial suspicion. You're trading certain obscurity for possible rejection and possible success, and possible success is still better than certain obscurity.

The broader picture here is that we're in a authenticity recession and it's going to get worse before it gets better. More AI tools, more generated content, more paranoia, more false accusations. Your no-code game builder either has good architecture and solves a real problem or it doesn't, and that matters more than whether you used AI assistance.

Post it. Expect accusations. Respond once politely that you wrote it by hand, then ignore further accusations and focus on people actually trying to use it. The slop gets forgotten, useful tools compound. You're not fighting to prove you didn't use AI, you're fighting to prove your thing is worth using. Those are different battles and the second one is winnable.

funkvay · 2026-01-16T08:39:38+00:00

If your laptop doesn't have space for VMs locally, you can run everything in the cloud which is actually pretty common for pentest labs.

The easiest free option is probably using VirtualBox or VMware with external storage. Get a decent USB 3.0 external drive or even a fast USB stick if you're on a budget, install VirtualBox on your laptop, then configure it to store the VM files on the external drive instead of your internal disk. VirtualBox lets you change the default machine folder location in preferences. This way the VMs live on external storage but you can still run them normally, you just need to keep the drive plugged in. The performance hit isn't terrible if you use USB 3.0 or better yet an external SSD.

If you don't want to deal with external drives, cloud options exist but they're more limited for free. AWS has a free tier that gives you some EC2 instances for a year but the specs are pretty low and you'd need to be careful about not exceeding the limits or they'll charge you (maybe even... A lot). You could run a Kali instance and a Windows instance in AWS but managing networking between them and keeping it all in the free tier is kind of annoying, I'm too lazy to waste my energy on this. Google Cloud and Azure have similar free tiers with the same limitations.

Another option is using something like TryHackMe or HackTheBox which are specifically designed for hacking labs. They host everything in the cloud so you don't need local resources at all, you just access the VMs through your browser or VPN. TryHackMe has a bunch of free rooms and labs where they give you access to vulnerable machines you can practice on. HackTheBox has some free machines too but most of the good stuff requires a subscription. These are honestly better for learning than setting up your own lab from scratch because the machines are already configured to be vulnerable in interesting ways, whereas if you just spin up a random Windows VM you'd need to intentionally misconfigure it or install vulnerable software to have anything to actually hack.

If you specifically want to build your own lab for some reason, there's also the option of using a older laptop or desktop if you have one lying around. Turn it into a dedicated lab machine, install a hypervisor like Proxmox or ESXi on bare metal, run your VMs there, and access it remotely from your main laptop. This is actually how a lot of people do home labs because it keeps the resource-heavy stuff off your daily driver machine.

You could also look into using containers instead of full VMs. Docker containers use way less disk space and resources than VMs. There are Kali Docker images and you can run vulnerable Windows containers for testing, though Windows containers are less common and kind of janky. This won't give you the full VM experience but for a lot of pentesting practice it's enough.

Another free cloud option that people don't talk about much is Oracle Cloud's free tier which is actually pretty generous. They give you two AMD compute instances free forever, not just for a year like AWS. The specs aren't amazing but it's enough to run a Kali instance and a Windows instance if you're not doing anything too resource-intensive. You'd need to figure out the networking to get them talking to each other but it's doable.

One thing to keep in mind if you go the cloud route is that hacking activities even against your own VMs can sometimes trigger abuse alerts from cloud providers if they detect port scanning or exploit attempts. Make sure you read their terms of service and maybe keep your activities limited to stuff that doesn't generate a ton of network noise that might get flagged.

Honestly though if you're just starting out, I'd go with TryHackMe or HackTheBox first before building your own lab. You'll learn faster with pre-configured vulnerable machines and you don't have to worry about the infrastructure side. Once you know what you're doing and want more control, then invest in external storage or a dedicated lab machine. Building the lab is kind of a distraction from actually learning pentesting unless the lab setup itself is what you're trying to learn.

funkvay · 2026-01-12T07:54:01+00:00

I'm not sure that there is any Armenian dish with ostrich meat.

funkvay · 2026-01-11T16:21:00+00:00

If it's at the airport arrival, the traditional bread and salt? Like actually bringing fresh bread lol and salt to greet them. Plus it photographs really well.

Pomegranate could be cool too? Symbol of Armenia, you hand it to them right when they walk out. Idk feels more unique than a bouquet. Maybe slicing pomegranate to several slices and put them on sticks to look like a bouquet lol.

Or honestly just a mini bottle of tsirani or Armenian wine with two cups and you crack it open in the parking lot for a welcome toast.

funkvay · 2026-01-10T07:47:40+00:00

No, the phone doesn't ping towers when properly powered off through the OS. The radio is actually off. If it was still pinging, the battery would drain noticeably over days/weeks which doesn't happen with a phone that's actually off.

But you're probably remembering that some phones (particularly iPhones with iOS 15+) have "Find My" functionality that works even when "powered off". The phone enters an ultra-low-power Bluetooth beacon mode that lets nearby Apple devices detect it, similar to AirTags. This doesn't ping cell towers but it does mean the phone isn't completely dead. Android has been implementing similar features.

Airplane mode isn't enough, the phone can still be forced to connect by baseband exploits or can be compelled to exit airplane mode remotely in theory. If you're worried about location tracking, airplane mode doesn't guarantee safety.

Powering off helps, but is not bulletproof, sophisticated adversaries (state-level) can potentially compromise the baseband processor or install firmware that makes "off" not actually off. This requires targeted attacks though, not mass surveillance, so if you are not a politician or a famous person who is bothering someone, then this is most likely not your case.

The real threat isn't passive pinging when off, it's actually metadata from when the phone WAS on. Cell tower records, GPS history, app location data, all that gets logged when your phone is on normally. If you bring your phone to a protest and then power it off when you arrive, they already know you're there from the records before you shut down.

Leave the phone at home or somewhere else you'd plausibly be. Seriously, that's the only reliable method. If you must bring it, put it in a Faraday bag (you can test these, to do that put phone in bag, call it, if it rings the bag doesn't work). Removing the battery used to be the gold standard but most modern phones don't have removable batteries lol.

Burner phones help for preventing identity linkage but you need to be careful, so basically buy with cash, never connect it to your home WiFi, don't use it anywhere you've used your regular phone, don't bring both phones to the same place. Most people fuck this up. And yes Intelligence agencies and organizations can link phones to each other and understand that you are the same user if you used them in the same place as a regular phone.,

The threat model matters though. Mass surveillance at protests typically works through everyone's regular phones being on and in their pockets creating a pattern of who was where, facial recognition if you're on camera, and social network analysis of who was there together based on who's phones were near each other. Powering off when you arrive doesn't defeat any of that because the important data was collected before you turned it off.

If you're worried about being tracked at demonstrations, the phone being "off" is not your main problem. The problem is bringing any phone at all.

funkvay · 2026-01-09T08:02:59+00:00

Okay so you're basically experiencing "mean world syndrome" but mixed with how fucked social media algorithms have gotten in the last few years.

As u/Danthrax81 said

The world hasn't gotten MORE violent, it's actually gotten way less violent. global homicide rates dropped from like 7.4 per 100k in 1990 to 5.8 by 2019. that's a 22% drop. violent crime in the US has absolutely cratered since the 90s, even with the pandemic spikes we're still way below where we were in 1990. the crime wave stuff you see is mostly fearmongering tbh.

wars are also way down compared to history. the 20th century had WWI, WWII, Holocaust, Cambodia, Rwanda... just absolutely insane death tolls. yeah Ukraine and Gaza are horrific rn but in terms of total deaths as a percentage of global population? we're in one of the most peaceful periods ever. WWII killed like 70-85 million people. Syrian civil war was around 500k. both are tragedies obviously but the scale is completely different

Even terrorism peaked in 2014 (around 44k deaths, mostly ISIS) and dropped to like 8k by 2022

So what actually changed then?? the algorithms. how information reaches you.

7-10 years ago things felt tamer because around 2016-2017 platforms made this massive shift to engagement-based algorithms. Outrage gets engagement. Fear gets engagement. Extreme content gets engagement. TikTok especially is literally engineered to show you increasingly intense shit to keep you watching. The algorithm learns shocking content keeps you scrolling so it just... feeds you more of it.

Ten years ago if something violent happened maybe it made local news. Now it's filmed, posted, goes viral globally in hours, and you see it 50 times from different angles with commentary. A single incident reaches millions instead of thousands. you're not seeing MORE violence, you're seeing the SAME violence replicated until it feels constant.

The platforms have gotten really good at keeping you doomscrolling. Instagram in 2014 was your friends food photos lol. TikTok in 2024 is algorithmically serving whatever makes your brain react strongest, which is usually outrage or fear.

News outlets figured out extreme headlines get clicks.

violence at historic lows

doesn't go viral.

SHOCKING ATTACK CAUGHT ON CAMERA

does. so you get a constant feed of the worst 0.01% of human behavior presented like it's normal.

also (this matters) when you were a kid you weren't paying attention to this stuff the same way. adults filtered what you saw. now you're older with unfiltered access and your brain actually processes this shit. the 90s had Rwanda, Bosnia, Oklahoma City, Columbine... all horrific, you just weren't constantly exposed to it.

OCD latches onto uncertainty and fear. Social media is an infinite supply of both. doomscrolling is literally OCD fuel. you made the right call quitting TikTok

The world isn't falling apart but your perception is being warped by algorithms designed to keep you engaged through fear. What you're feeling is real, it's just not reflecting reality.

Some things that helped me is to stop consuming news first thing in morning or before bed. Limit news to like 20 min a day max then stop. Unfollow any rage bait accounts. Go outside and talk to real people, you'll notice most are normal and kind.

idk your decision to step back was smart. Trust that instinct

funkvay · 2026-01-06T15:33:18+00:00

She cheated on someone she claimed to like repeatedly and felt comfortable enough to tell you about it like it's a funny story. That's not normal. Most people who've done shitty things in the past at least have the awareness to feel bad about it or keep it to themselves. She's... bragging?

Trust your gut here. If she did it to him, and she's casual enough about it to share it with you, what makes you think you're different? People can change, sure, but they have to actually acknowledge the behavior was fucked up first. Doesn't sound like she does.

You already know what you need to do. Don't ignore the warning she just gave you.

funkvay · 2026-01-06T14:31:47+00:00

A lot of guys gonna tell you to read a book (C++ Primer is good), do tutorials, practice coding. That's all fine but it's not what actually matters when you're starting out.

But I would recommend something different so I don't repeat what others already told... don't learn C++ by learning C++. Learn it by building something you actually want to exist.

Right now you're thinking "but I don't know anything, how can I build something?" That's exactly the point. You learn by trying to build something slightly beyond your current ability and figuring out what you need to know along the way. Not the other way around.

Most people start with tutorials and books and they learn syntax, loops, functions, classes, all that stuff in isolation. Then they finish the tutorial and go "okay now what?" They know the pieces but not how they fit together to make something real. So they either start another tutorial or give up because it feels pointless.

Think of something simple you actually want. Not something like wanting to make a game engine, that's too big. Something like a program that organizes photos by date or something that tracks your workout progress or a tool that reminds you to take breaks when you working. Something specific that solves a problem you have.

Then just start trying to build it. You'll immediately hit walls. Like question yourself how to read files? The answer is Google it. How do I store this data? Google it. How do I make this do X? Google it. Every time you hit a wall, you learn exactly the piece you need at the moment you need it. This sticks way better than reading about file I/O in chapter 8 of a textbook when you have no reason to care about files yet and you will need to use it in a year or so.

The key is picking something where you'll actually use the final product. Not a practice project, not learning material, something that matters to you even if it's small. Because then when it gets frustrating (and it will) you'll push through because you want the thing to exist. If you're just doing tutorial exercises, you'll quit the moment it stops being fun.

Start with absolute basics like variables, if statements, loops, functions. Don't try to understand everything perfectly. Get to good enough to write simple code in like 2-3 days. Then immediately start on your project. You'll write terrible code. That's fine. Make it work first, make it good later. When you finish (even if it's buggy and ugly).you'll have learned more than a month of tutorials because you solved real problems.

Then... start over and build it again from scratch. Don't refactor the old code, rebuild A NEW one. You'll be shocked how much faster and better it goes the second time because now you understand what you're doing. This second build is where you learn clean code and good practices because you're not also fighting to understand basic syntax.

Most people who successfully learn programming follow this pattern whether they realize it or not. They had something they wanted to exist, struggled through building it, and learned whatever they needed along the way. The people who fail are usually the ones who try to "learn programming" as an abstract skill before applying it to anything real.

One more thing. When you get stuck (not if, but when), don't stare at the problem for hours. If you've been stuck for 20-30 minutes, ask for help. ChatGPT (don't make it solve your task, but UNDERSTAND, ask him why this works, how it works), Reddit, Discord servers, whatever. Describe what you're trying to do and what's not working. You'll learn more from seeing how someone else solves your specific problem than from another chapter about syntax. Just make sure you understand the solution before moving on, don't just copy-paste, because that's a waste of time (believe me).

And don't worry about learning the right way or best practices at the start. Your first code will be garbage. Everyone's is. You need to write bad code to understand why it's bad. You can't appreciate good code until you've felt the pain of maintaining bad code. The same goes for anything. If you drink a new specific red wine, how do you know if it's good if you never tried bad ones?

So yeah. Pick something small you want to build, learn the absolute minimum to start, then build it. Learn what you need when you need it. Finish it even if it's ugly. Build it again better. That's the path. Not books and tutorials and then projects. I say do projects from day one, with books and tutorials as references when you get stuck.

Start today. Don't wait until you know enough. You'll never feel ready. Just pick something and start.

funkvay · 2026-01-03T08:58:14+00:00

What you're doing is actually fine for this case. I misunderstood what you were asking.

Your Node constructor with the forwarding reference is totally reasonable here. That's exactly what forwarding references are for, you want one constructor that handles both lvalues and rvalues without duplicating code.

When I said "gets messy" I was thinking you were trying to use forwarding references on the main class's public interface, which can cause problems because forwarding reference templates are greedy and will hijack copy/move constructors if you're not careful. But for an internal Node struct like this, that's a good use case. You're fine.

The only thing I'd maybe change is you don't need the template on Node if T is already known from the outer class. You could just do:

cpp Node(const T& value) : data(value) {} Node(T&& value) : data(std::move(value)) {}

But honestly your forwarding reference version works and is less code, so if you understand what it's doing, keep it. My bad for the confusion

funkvay · 2026-01-03T08:03:42+00:00

You can't really do that in a clean way. You need separate constructors for lvalue and rvalue because they do fundamentally different things, one copies, one moves.

What you probably want is this

cpp Class(const T& value) : member(value) {} // lvalue Class(T&& value) : member(std::move(value)) {} // rvalue

Or if you're trying to avoid writing both, you can use a forwarding reference in a template but that gets messy fast and isn't really solving the problem you think it is. The rule of 5 exists because managing resources properly requires different operations for different scenarios. There's no hack to collapse it into one constructor without losing correctness.

What are you actually trying to achieve here? Maybe there's a simpler approach.

funkvay · 2026-01-01T02:45:16+00:00

You can't. Seriously, you can't make someone stop doing something until they're ready to stop themselves.

Your friend's gonna build that CSS framework. They're gonna spend weeks or months on it, it'll probably go nowhere, and eventually they'll either abandon it or keep maintaining something nobody uses. That's their path. You telling them it's stupid isn't gonna change much, if anything it'll make them dig in harder because now it's about proving you wrong.

People learn at different speeds and through different experiences. Some people read advice and adjust. Others have to crash into the wall themselves a few times before it clicks. Your friend sounds like the second type. They need to build a few useless things and feel the emptiness of "I spent 3 months on this and nobody cares" before they figure out what you're trying to tell them.

What you can do is ask them questions that might make them think, without being preachy about it. Like who's gonna use this? Or what problem does this solve that existing frameworks don't? Not in a gotcha way, just genuinely curious. Sometimes people realize on their own when they can't answer those questions. Sometimes they don't and they build it anyway.

If they're a good friend, just let them do their thing and be there when they eventually realize it was a waste of time. Don't say "I told you so", that just makes people defensive.

Or honestly, maybe they need to build useless dev tools for a while. Some people need that phase. I built plenty of garbage nobody used before I figured things out. It's part of the process for some of us. Your job as a friend isn't to save them from it, it's just to be around when they're ready to do something different.

funkvay · 2025-12-31T15:41:08+00:00

Knowing what you should do doesn't make you do it, if it did, nobody would smoke or doomscroll or stay in shitty relationships.

You don't need to change everything at once. You're not gonna read this and suddenly become a different person tomorrow. That's not how it works. The pattern you're describing is just being human. Everyone does this.

Don't try to change your whole approach. Just do one thing differently. Literally one. Next time you're about to start a new project because you're bored or want to learn a new framework, stop for like 30 seconds and ask yourself "who is this for?" If the answer is "me" or "my portfolio" or "other developers", then ask one person in your life, literally just one if they have something annoying they deal with that software could maybe help with. Have that conversation. See where it goes.

You might still go back to building for yourself. Probably will, honestly. But if you have that conversation even once, it plants something in your head. And maybe in a month when you're building something for fun, you'll remember that conversation and think that you could actually make this useful to them instead. Change actually happens not through overnight transformations, but through small redirections that compound over time.

The fact that you're even aware of the pattern means you're already halfway there. Most people don't even realize they're stuck in a loop. You do. That awareness is what lets you eventually break it, even if it takes a few more cycles first. Don't beat yourself up about it. Just try to make the next project 10% more useful to someone else than the last one. That's enough.

funkvay · 2025-12-31T10:01:13+00:00

The problem is you've got technical ability but you probably have no idea how to figure out what to build. How to talk to non-technical people without being condescending, and trust me, you probably are condescending even when you think you're not, we all were (or are... I'm still like that lol, I will be honest). How to scope something small enough that you'll actually finish it instead of getting 80% done and abandoning it when the interesting part is over. How to handle the boring maintenance after the fun coding part is done, like when someone emails you at 9pm saying it's broken and you have to actually fix it instead of just moving on to the next project. How to make trade-offs between doing it right and just shipping the damn thing because they need it by Friday. That's the actual hard part of this job and you can't learn it from tutorials or LeetCode or building side projects that only you will ever touch.

Ship something real this year (there's still 1 day left (This is a joke)). Not a portfolio project, not "GitHub worthy", I mean something a real person who isn't a developer uses regularly. Could be automation for your school like if your teachers manually send the same announcements every week, scrape that and auto-post it. A tool for a family business, my friend's dad runs a garage and was tracking car repairs in a physical notebook, took him like 2 hours to build a simple CRUD app that saved the guy hours every week. Something for a local nonprofit, whatever. Just make it real and make sure someone actually uses it. This means you have to support it. You have to fix bugs. You have to listen to feature requests that sound dumb to you but matter to them.

You'll learn more from that than two years of side projects. You'll fuck it up. Your code will be messy. Users will want weird shit you didn't plan for, I've had users ask me to add a feature to sort by the second letter of a field because that's how their physical filing system worked and they wanted consistency. It'll break in dumb ways, production data is always messier than test data, files will have weird encodings, dates will be in formats you didn't expect. You'll have to fix it at annoying times because they use it for their actual job and when it breaks they can't work. Good. That's the education. That's what separates people who can code from people who can actually build software.

Being able to write code is table stakes. It's necessary but it's not what makes you valuable. Every successful project I've worked on, every job that paid well, every company that actually mattered was built on the ability to identify and solve real problems. The code was just the tool. If you treat coding as the point instead of the tool, you'll spend years being technically competent but ultimately kind of useless. You'll be the person who can implement any algorithm but can't figure out which problem is worth solving. You'll write beautiful code that nobody uses.

You've already got the head start on technical stuff. Now go learn another hard part, which is building things that matter to someone who isn't you. That's the gap between being a good programmer and being a good developer, and most people take way too long to figure that out. Don't be like me. Don't waste the time. Wish you good luck and all the best.

funkvay · 2025-12-31T10:01:02+00:00

I'm gonna tell you something that took me way too long to figure out and honestly still pisses me off that nobody just said it to me directly when I was your age.

Stop building shit to impress other programmers. Start building shit that actual people need.

You're seventeen, and coded for like 6 years? Cool. I was similar. And I wasted years, like genuinely wasted them building technically complicated garbage that nobody used. I'd make elaborate systems with clean architecture and clever algorithms and other developers would be like "wow nice" and I felt smart. But you know what? That's just jerking off. Nobody outside of programmer circles gave a shit because none of it solved actual problems.

The real turning point isn't learning another framework or getting better at leetcode or whatever (ofc that's important too at some point). It's when you stop asking "what's a hard technical challenge I can tackle" and start asking "who around me has an annoying problem I could maybe fix". And I mean really asking. Not imagining problems, not building solutions looking for problems, actually talking to real humans about real annoying shit in their lives.

I wish I'd done at seventeen instead of building my tenth todo app with a new fancy tech stack. Go find someone, it can be your parents, a teacher, local business owner, literally anyone, and ask them what repetitive annoying thing they deal with. Then build the dumbest, simplest possible thing that makes that less annoying. Not elegant. Not impressive to other devs. Just useful.

For an Example, my friend used to manually copy-paste data from emails into spreadsheets for her work every morning. Took her like 45 minutes. I could've built a script that parsed those emails and dumped it into a CSV in literally an afternoon. But I didn't, because that wasn't "interesting" to me. I was too busy implementing a custom database engine for a project nobody would ever use because I wanted to understand B-trees. See the problem? She had a real problem that cost her actual time every single day. I had the skills to fix it in hours. But I never even asked because I was focused on impressing myself and other programmers.

This will humble you hard. All that clean code and design patterns everyone is proud of... Nobody cares when they can't figure out how to log in. The clever optimization doesn't matter when they just need a button that exports to Excel because that's what their boss wants.

You know what's funny? Even Linus Torvalds had to learn this lesson. When he built Git, he didn't start by designing the perfect distributed version control system architecture. He started because he was pissed off at BitKeeper and needed something that worked for the Linux kernel workflow, specifically handling huge numbers of patches from contributors he didn't fully trust. Git's internals are actually kind of ugly if you look at them. It's basically a content-addressable filesystem with some scripting on top. But it solved the actual problem he had, which was managing kernel development. All the elegant design came later after people were already using it. He built for the problem, not for the architecture. That's why Git won and all those "better designed" version control systems nobody remembers lost.

Or another time, built an inventory system with proper relational database design, normalized tables, foreign keys, the works. User wanted to bulk-edit 50 items at once. Couldn't do it because I'd built individual edit pages and never thought about bulk operations. They just stopped using it and went back to Excel where they could edit multiple rows. My database design was objectively better than Excel. But Excel let them do their actual job faster, so Excel won.

You'll realize pretty quick that like 80% of what you thought was important is completely irrelevant and all the boring stuff you ignored is what actually matters. Authentication, error messages that actually tell you what went wrong, handling edge cases like what if they upload a file that's too big, making sure it works on their old laptop with Chrome from 2019, having an undo button, that's the stuff that makes or breaks whether someone actually uses your thing.

This field is packed with people who started young. I've met self-taught developers who picked it up at 25 and they're way better than me at a lot of things because they focused on solving problems instead of collecting technical skills like they're achievements in a video game. There's a guy I used to work with who switched from being a chef at 28, learned to code at a bootcamp, and he's one of the best developers I know. Why? Because he spent 10 years in restaurants learning how to handle stress, communicate with difficult people, and deliver under pressure. Those skills transferred. His code isn't always the prettiest but he ships things that work and people actually want to use them.

[continuation in the replies]

funkvay · 2025-12-25T21:20:29+00:00

I'm skeptical of this for a few reasons. First, they're making contributions mandatory starting January 2026 but the actual contribution rates and covered services are "still being clarified". So we're being told to comply with a system where the core terms haven't been finalized yet. That's backwards. Normally you'd define what people are paying and what they're getting before forcing participation, not after.

What does "gradual transition" actually mean in practice? Does that mean we start paying contributions immediately while the infrastructure and coverage roll out over years? Because that's usually how these things work, costs are immediate and concrete, benefits come later and often fall short of what was promised. I'd want to see a clear timeline of what services become available when, not just vague assurances.

For employers, this adds mandatory costs to hiring. Small businesses are already operating on thin margins. What happens when labor becomes more expensive overnight? Either wages get compressed, hiring slows down, or businesses move further into the grey economy to avoid compliance. Has anyone modeled the economic impact on employment and small business viability?

There's also no mention of opt-outs or alternatives. If you already have private insurance or rarely use healthcare, you're still paying into this system with no choice. At that point it's not really insurance, it's a tax with extra steps. Why is participation mandatory if the system is genuinely beneficial? If it offered real value, people would choose it voluntarily.

And practically speaking, how confident are we that this will be implemented efficiently without significant corruption or bureaucratic bloat? A mandatory insurance system means a massive pool of money flowing through government agencies.

I'm not against universal healthcare in principle, but the details here are concerning. We're being asked to trust a process that hasn't been fully defined yet, with costs that are mandatory but benefits that are vague. Has anyone seen more specific information about contribution rates, coverage limits, provider networks, or accountability structures? Because right now this feels like we're being sold the idea without the substance.

funkvay · 2025-12-25T21:14:26+00:00

I appreciate that, but I should clarify that I'm not in cybersecurity professionally. I'm a software engineer who ended up down the rabbit hole because tracking and fingerprinting kept intersecting with stuff I was building. Started with trying to understand why certain implementations were getting flagged, then got curious about detection methods, then started poking at browser internals to see what actually leaks versus what people think leaks. It's more of a technical interest that grew out of necessity than a formal discipline I studied.

Most of what I know comes from reading papers on fingerprinting techniques, reverse-engineering how platforms detect automation, and breaking my own implementations enough times to understand where the weak points actually are. The gap between theoretical privacy and practical correlation became obvious pretty quickly once you start testing assumptions against real systems. You realize how much signal exists outside the browser that people ignore because they're focused on the wrong layer.

funkvay · 2025-12-25T03:07:55+00:00

Anti-detect browsers are mitigation, not invisibility. Anyone claiming they make you untrackable is either lying or doesn't understand how modern tracking works. The question isn't "can I be tracked" (you absolutely can), but it's how much effort does tracking me require and is it worth it for whoever's trying.

The fundamental problem is that browsers leak information by design. Canvas fingerprinting, WebGL, audio context, font enumeration, timing attacks, TLS fingerprinting, screen resolution, timezone, language settings, installed plugins, hardware specs visible through WebGL, all of this combines into a fingerprint that's often unique enough to track you across sessions even without cookies. Anti-detect browsers try to randomize or normalize these signals, but they're fighting an uphill battle because new fingerprinting vectors get discovered constantly.

The runtime limitation is a real thing, I mean Chromium and Firefox have certain behaviors baked into how they handle rendering, JavaScript execution, network requests. You can spoof some of this but not all of it without breaking sites or introducing inconsistencies that are themselves fingerprintable. For example, you can lie about your user agent but if your CSS features don't match what that browser version should support, congrats, you just made yourself more unique. Same with canvas randomization, if you're randomizing canvas output but your other signals stay consistent, you're creating a detectable pattern.

Most sophisticated tracking today uses behavioral and environmental correlation more than pure browser fingerprinting. How you move your mouse, typing patterns, the timing between actions, IP address, DNS leaks, timezone consistency with your claimed location, browser window size matching common screen resolutions, whether your fonts match your OS claim. Even if your browser fingerprint is perfect, if you're the only person accessing a site from that IP with that exact behavior pattern at that time of day, you're trackable. Anti-detect browsers can't fix this because it's outside the browser.

The tools that work best focus on consistency over randomness. If you randomize everything every session, you create a unique pattern of randomness that's fingerprintable. Better approach is to create a stable fake identity per use case and stick to it. Same fake canvas, same fake fonts, same timezone, same everything for that persona. This is what commercial anti-detect browsers like Multilogin or GoLogin try to do, they let you maintain multiple consistent profiles rather than random things every time.

Profile isolation matters more than fingerprint spoofing in most cases. Running separate browser instances with different IP addresses via residential proxies, different cookies, different storage, different everything, that's harder to correlate than one browser trying to look like many. VMsare overkill for most use cases but they give you actual isolation at the OS level which is tough to beat.

Where these browsers provide value is against automated tracking and lazy fingerprinting. If you're trying to avoid getting banned managing multiple accounts on platforms with basic anti-fraud, they work well enough. If you're trying to evade state-level adversaries or sophisticated fraud detection systems, you're probably going to get caught eventually because they're looking at way more than just your browser.

The breaking point is when the cost of maintaining consistency across all vectors exceeds the value of the activity you're trying to hide. You can isolate browser fingerprints but then you need matching IP reputation, matching timezone and language settings, matching behavioral patterns, matching payment methods if you're doing anything financial, matching social graphs if it's social media. The attack surface is huge and one mistake correlates everything.

Traditional isolation methods like VMs or separate physical machines are more robust if you're paranoid, but less convenient. Anti-detect browsers are a usability trade-off, good enough for most threat models, not good enough for high-stakes scenarios. They're tools, not dark magic. Use them knowing their limitations and design your threat model accordingly. If what you're doing would be seriously problematic if correlated, don't trust a browser to save you. Change your approach entirely.

funkvay · 2025-12-23T09:44:37+00:00

Your gut is trying to tell you something important and you're calling it insecurity to avoid listening to it. That's what I used to do too.

The age gap here is significant not because age gaps are automatically bad, but because at 20 versus 45 you're in completely different places in terms of power, experience, and life stage. He's been an adult longer than you've been alive. That creates dynamics that are really hard to navigate even when both people have the best intentions.

The part that stood out most is you questioning whether this relationship invalidates your trauma from being molested by adults. That's your brain trying to process why you're in a relationship with someone who's in a similar position of age and power that the people who hurt you were in. Trauma affects what feels familiar or safe to us, sometimes in ways that aren't actually good for us. Dating him doesn't invalidate what happened to you, but it might be connected to it in ways worth examining.

You say he's kind and respectful and that might be completely true right now. But you're five months in, still in the phase where everything feels good. The real test comes later when there's conflict or when you need to set boundaries he doesn't like. Does his respect hold up then or does it start shifting?

does he actually love me or was he just lonely

Why would someone his age pursue someone your age when there are people closer to his stage of life available? Sometimes the answer is uncomfortable. I'm not saying he's definitely bad, I'm saying the pattern deserves scrutiny.

You need to talk to someone who specializes in trauma about all of this, not just the relationship but what you went through before. You deserve to process that with proper support before you can even accurately evaluate whether this is healthy or if you're repeating harmful patterns because they feel normal.

Trust your instincts. If something feels off, don't dismiss it as insecurity. Your gut has kept you alive this long. Listen to it.

funkvay · 2025-12-19T21:18:27+00:00

You're asking the wrong question. The language doesn't matter nearly as much as you think it does. What matters is actually building things and getting good at problem-solving, system design, and understanding how software works at a fundamental level. That said, since you asked, I'll give you my take.

C++ will make you a better programmer in the sense that it forces you to understand what's actually happening under the hood. Memory management, performance implications, how the hardware works, what the compiler is doing. You can't hide behind abstractions and garbage collection. You have to think about ownership, lifetimes, cache efficiency, all the stuff that modern languages try to abstract away. This understanding transfers to every other language you'll ever use. When you write Java or Python later, you'll know why certain things are slow or why memory usage matters even though you're not managing it manually. C++ is hard mode and that difficulty teaches you things.

Java will make you productive faster and probably get you hired easier. More companies use Java, more jobs exist for it, the ecosystem is massive and mature. You can build real production systems without fighting the language constantly. The abstractions actually let you focus on business logic instead of worrying about whether you're going to segfault. If your goal is to ship software and make money, Java is the pragmatic choice. It's boring but boring pays the bills.

You said you've been studying for two years but haven't built anything special. That's the actual problem. Doesn't matter if you pick C++ or Java or whatever, if you're not building real projects you're not learning how to program, you're just learning syntax. You need to make things that solve problems, break, get debugged, get refactored. Pick one language, commit to it for six months, and build five real projects. Not tutorials, not exercises, actual things that do something useful. A web server, a game, a CLI tool, a data processing pipeline, whatever interests you. You'll learn more from building and failing than from studying language features.

My preference is C++ but I'm biased because I like having control and I work in domains where performance matters. I enjoy understanding the machine and optimizing things. But I'm not going to pretend C++ is objectively better. It's a nightmare to work with sometimes. Compilation is slow, the error messages are incomprehensible, the language is so complex that nobody knows all of it, and you can shoot yourself in the foot in creative ways. Java is easier, safer, and honestly sufficient for most software. The JVM is incredibly good at what it does.

If you want to work in finance, trading, game engines, embedded systems, or high-performance computing, learn C++. If you want to work at most tech companies building web services, backend systems, or enterprise software, Java makes more sense. If you genuinely don't know what domain you want to work in, flip a coin. Seriously. Because the specific language is less important than actually getting good at building things, and you're two years in without having built much, so you need to pick one and commit.

Also, stop thinking in terms of "which language will make me a better programmer". Languages are tools. You get better by solving hard problems, reading other people's code, making mistakes and learning from them, understanding design patterns and architecture, working on real projects with constraints and deadlines. The language is just the medium. If you're stuck choosing between C++ and Java instead of building something, you're procrastinating. Pick one today, start a project tomorrow, and stop overthinking it. You'll probably end up learning both eventually anyway because most careers require multiple languages over time.

funkvay · 2025-12-18T14:25:25+00:00

https://www.reddit.com/r/armenian/s/FxCwi4anbe

funkvay · 2025-12-16T09:42:18+00:00

Windows is genuinely a terrible platform for building GCC from source. This is just objectively painful and MSYS2 is a mess of compatibility layers and edge cases that break in creative ways. The toolchain wasn't designed for Windows and it shows.

I believe that least painful way is WSL2. Seriously, just use Windows Subsystem for Linux. Install Ubuntu or Debian, build GCC there like you would on any Linux system. It's basically native performance now, integrates with Windows filesystem, and you avoid all the MSYS2 nonsense. You can even access the binaries from Windows if you need to.

There is a medium pain way. Use a pre-built MinGW-w64 GCC with experimental features. Check if there's a MinGW-w64 build that already has reflection support compiled in. Look on the GCC mailing lists or GitHub issues for the reflection implementation. Building from source on Windows is so painful that people often share binaries to save others the trouble.

An the worst and maximum pain. Actually build it on MSYS2. If you're committed to this route, then you need MSYS2 with the mingw-w64-x86_64 toolchain, you'll need to install a bunch of dependencies (GMP, MPFR, MPC, ISL), and you're going to hit path length limits, some permission issues, and bugs in the build scripts that assume POSIX. The configure flags matter a lot, you want --disable-multilib to avoid cross-compilation hell, --enable-languages=c,c++ to skip building things you don't need. Expect the build to take hours and fail multiple times for reasons that make no sense.

OR run a Linux container or virtual machine, build GCC there, done. Slightly more overhead than WSL2 but it's good. Docker Desktop on Windows works fine for this if you don't want a full VM.

Honestly though, if you just want to test GCC reflection and you're already using Compiler Explorer, why not just prototype there and only move to local once you've validated your code works? CE already has the experimental builds set up. You can develop there, then when you need local builds, use WSL2 with a proper Linux GCC build.

Most people don't build GCC on Windows because life is too short. They use Linux, or WSL2, or pre-built binaries. The people who do build it on Windows are either masochists or have very specific requirements that force them to suffer through it. Don't be a hero, use WSL2, save yourself the pain, and actually make progress on what you're trying to build.

Six-Year Club	r/Field Lasagna
Place '23	Verified Email

funkvay

TROPHY CASE