blyry

I don't have a ton of experience with other options, but 2 weeks in and tumbleweed has been pretty plug and play! 0 issues getting my netcore/python/golang/docker dev stack up. I get a weird popping noise in my usb dac at the login screen but that's the only issue I've had so far. Teams screen sharing even works perfectly! I chose it over Ubuntu 20 because I knew I wanted kde and it seems like a first class citizen in tumbleweed, while still being vaguely stable. Not-quite-bleeding edge! I ran freebsd/kde for fun back in the halycon days of lamp stack and gnome never felt...right to me when I would test drive Ubuntu desktop.

I switched to a linux desktop full time last week because of this exact problem. VPN w/ windows would flake out on me all the time, and I got sooo tired of just...waiting. Remember when windows search worked? Like, you could press the windows key, type what you were looking for and find it? Quickly?

Being able to turn the computer on, type in my password and have it be just..ready is so incredibly refreshing. Having a terminal with 0 latency, where copy/paste is sane? Worth a zillion dollars to me right now.

Currently playing with opensuse tumbleweed, i'll probably get frustrated by something and move to arch, so I can fix that something and also be frustrated by a hundred other things.

> It will collapse files with over 100-200 lines of changes for seemingly no reason (hiding the comments within them)

OH MY GOD this so much. This one specific anti-feature has no doubt caused countless bugs to be missed during code review. I can quote the issue thread by memory at this point i've revisited it so many times the last year(s?)

For goodness sake, if the trade off is between 'seeing all of the changes during the review' vs 'having the page load quickly', the only people who choose 'quickly' are those who haven't been burned by human error missing a collapsed diff. Gitlab made the wrong trade off here in good/fast/cheap triangle.

We stopped using gitlabs artifact repositories for this exact reason!

That got us on k8s faster and gave us time to evaluate if we /really/ needed a service mesh or not (we don't, but the tracing is nice so we might still add istio yet). We may move to ingress based solutions eventually but our ecosystem is big and there's a lot more bigger fish to fry for now!

When we migrated to k8s we stuck with haproxy instead of using ingress for some of the reasons others have outlined already -- we've been running haproxy for a decade. Our configurations are tuned for our applications, we know the cpu usage and failure modes, and haproxy 1.9/2x support for srv records made it really easy. Bring able to trust k8s and our health checks and drop our previous 3 vm + vrrp setup was a no brainer!

YES! We have been using hound for several years now, having all hundreds of our org repos searchable in one spot, in a LIGHTNING FAST manner has been an invaluable tool to help our various teams keep up with the legacy sprawl and effectively remove old features and all their dependencies from our sprawly systems. I even wrote a microservice that uses gitlab global hooks to keep hound up to date without polling, and a little c# config generator that runs as a cron job on our gitlab instance and redeploys hound with the newest repos included.

Hound falls short on access control front (we wrapped our instance with a saml proxy), but it's still a 'you either can search every piece of software for \'password\'' or you don't have any access at all. Having to index a specific branch instead of all of them kinda stinks too; for those two specific reasons we have been eyeing sourcegraph, esp. as the gitlab integration matures.

I can't emphasize enough how fast hound is and how pleasurable it is having a regex based code search that doesn't make me wait.

Can confirm, it's all about the buy box. My company offers free 1 and 2 day shipping to all customers across all channels in as many zips as our fc network allows. SFP gets us the buy box with a way higher percentage and gives us a significant boost in our Amazon revenue.

My school hacking story: 7th grade, springtime, ~1998. The district used software that ran on login and populated your desktop/start menu and permissions. This was a mixed network of windows 98 and XP for all the newer computers. I found a bug where if you corrupted your own user profile folder, windows would load a temporary one after reboot and not apply all the restrictions, giving access to explorer. You could also get access to explorer by going through the f1 help menu in a couple of different programs.

Promptly used explorer to navigate to my english teachers computer via the hidden c$ share, and delete the executable from the program files folder. Next time she logged in, BOOM nothing. no start menu, no desktop, no permissions. The admins had an incredibly consistent and predictable naming scheme, and my idiot "friends" I shared the vulnerability with promptly used this to nuke like 3 labs and a bunch of teachers computers.

Fast forward 1 month, we all got pulled out of PE by a cop and sentenced to 1-3 weeks of community service.

* I abused that profile bug to work exclusively out of portable firefox on a usb drive instead of being tied to internet explorer 6 and 7, which allowed me to bypass proxy settings and get access to gmail and read slashdot/ign/halo.bungie.org during school hours! Those were the days.

My employer switched to dell laptops, the first gen xps 15 and 13s, and now the precisions. As they get older we're seeing more and more battery swell. We're not sure the root cause, we speculate that it's a specific usage pattern related to the USB-C docks everyone has. Your battery is definitely not okay, you should get it replaced asap. We've looked at some alternatives like the hp spectre, or the lenovo ideapad and the asus zenbook, but none of the felt as nice as the precision line wrt build quality and bang-for-buck.

We use elasticsearch to power our ecommerce search, and it works pretty well, but we're considering moving to a commercial product, or solr, to get closer to personalized results based on our knowledge about the user.

We just rewrote our internal search API from a windows service indexer with lucene indices and a vb.net SOAP api in iis to a netcore service, hosted in k8s, that splits out ingest, analysis, storage and queries into separate domains, with the writes going to Azure Search Service*.

Our use case might be a bit weird -- this app is essentially an internal API that supports the search needs of our other teams and their own products for our own internal software. It probably has 30 million records across a few different indices. We made the decision to migrate from lucene because of the ease of clustering elasticsearch. We previously achieved availability by just running multiple copies of the standalone service and doing smart health checks at the load balancer level in case a lucene index got corrupted and needed to spend a day rebuilding, but that didn't scale well for rebuild times, and we have been consolidating all of our legacy tech onto netcore and kubernetes.

Raw lucene was an order of magnitude faster than azure search service, but that's probably more a function of being able to essentially query the indices directly in memory of the webservice, as opposed to a slightly underprovisioned search cluster with all the HTTP overhead. We're migrating it to our own elasticsearch cluster right now for performance, cost savings and cloud-agnosticism.

I used arsclip for this. Your UI is nicer though. -- [http://www.joejoesoft.com/vcms/97/]