How are you supposed to distribute programs written in #python these days? You used to be able to package it up and put it on PyPI and tell people to just pip install it, but now that pip doesn't work without a virtualenv, what's the replacement?
I don't view telling people to pass --break-system-packages to be a good solution, I would rather want to avoid telling users to "break system packages"
@mort How about telling them to create a virtualenv and then pip-install it?
It depends on your use case, but I always had the best results by using the official distribution method of the platform you target. That's an exe file for windows, appimage for macs, and distro packages for various linux distros. The users don't even need to know it's written in python then.
@deshipu Asking a user to create a virtualenv/venv/pipenv/pyenv and then remember to activate that virtualenv/venv/pipenv/pyenv every time they want to run the program is unimaginably terrible UX.
The #CVE count of the #Linux#kernel is not looking good these days compared to any other #OS is it. Maybe time to switch to #FreeBSD or some other system which doesn't claim to find hundreds of significant vulnerabilities every day
But no seriously what the fuck is @gregkh trying to achieve here? Before, I could use a CVE count as an argument to spend time upgrading #Linux: "there have been found 5 vulnerabilities in the version we use, we should upgrade to the latest". These days, CVEs are useless for that purpose, everyone knows that pretty much every single one of the thousands of "CVEs" affecting the kernel version we're on is bogus so they aren't useful for that purpose any more so we stay on old kernels for longer
@vbabka@mort@ljs@mcepl I am not trolling anything, I am working within the requirements of the CVE system at the request of the people who run it. We are doing so because other entities were abusing the CVE system for the Linux project in the past, so in order to take control of it, we must work within the constraints with which we are placed.
And that means assigning CVEs to everything that meets the definition of vulnerability as defined by cve.org. If you, or anyone else notices a CVE we issue that does NOT meet that definition, please let us know and we will be glad to reject it.
Odds are other operating system kernels will start doing the same as Linux does, if they wish to be a CNA for their project. We aren't alone here, it's just that we report our fixes, others don't, or aren't actually developing any fixes. You be the judge of which is the case for various projects :)
I really like #kotlin's (and others') approach to nullability, where nothing is nullable by default and you mark something as nullable by adding '?' to the type. And the '?.' syntax is nice too. 'foo: Foo? = ...; foo?.doThing()' is nicer than 'foo: Optional<Foo> = ...; foo.map(|it| it.doThing())', and both are miles better than "everything is always implicitly nullable unless annotated with '@NotNull' #plt
The whole #KeePassXC#Debian thing is kinda giving me second thoughts wrt. the whole #Linux distro and #opensource packaging thing in general. My understanding of the implied agreement between me as a dev and a distro's package maintainer is: the maintainer, to the best of their ability, tries to make my software work "as intended". In return, they get to publish it under my software's name.
That's clearly not how Debian views things. And I can't accept distros publishing broken sw w/ my name.
@deshipu Yeah, I get that. But the "threat model" here isn't really "someone else writes different software and releases it under the same name as my software", but "Debian takes my source code, breaks it in key ways, and releases it under the same name"
I can't deal with languages with optional semicolons! I like languages without semicolons, but when they're optional, especially if they feel "C-like", I always end up adding semicolons to some lines even when I try to write in a semicolon-less style. I'm writing some #kotlin now and I decided to just use semicolons consistently because the alternative is seemingly to use them inconsistently.
Strangely, this isn't an issue I have in #golang. I do have it in #rust however.
@ekuber That's correct, and I would've added a caveat if I wasn't limited to 512 characters, but here we are
For a whole lot of blocks in rust (such as if statements and loops not used as expressions), it doesn't make a difference whether the block technically evaluates to something, so the last semicolon there is in practice optional, so I sometimes forget it
Hey y'all if you have an object notation you wanna call NBON, and it stands for Non-Binary Object Notation, is it fun and cute to make this the logo or is it disrespectful
I feel like if I was non-binary I wouldn't hesitate to make this the logo for something but since I'm not, I'm not sure it's right for me to appropriate it? Thoughts?
On #Linux, my game runs perfectly smoothly with just vsync enabled, but I always had issues with stutters on #macOS, letting the game loop be speed limited only by vsync resulted in an incredibly choppy experience and I would get weird frame rates like 105 FPS on my 120Hz screen
Turns out that implementing a manual frame rate cap fixes it, I now sleep for (1/fpscap - dt) at the start of the game loop and it's buttery smooth 🤷
Huh wow, TIL #redis never had a contributor license agreement.
Does that make this the first high-profile case of a previously-FOSS project relicensing while having a bunch of contributions made by people who didn't consent to the license change? ..How is that going to go down #opensource
@nemobis@mort and it seems like open tofu, the project that forked it is having little trouble getting support. That still leaves the issue of massive firms freeriding on open source without contributing. It does seem the community needs better licenses, perhaps even contractual agreements
@marcus_grant Yes, clarifying mutual expectations is good. If a contract on top of the license helps, so be it.
I'm not convinced it's primarily a legal issue: to this day, if you're a self-hosted user of #HashiCorp#FreeSoftware, you have no way to throw money at HashiCorp even if you want to.
Does anyone know how to get #vim or #neovim's C and C++ indenter to indent switch statements sanely? I don't want this sort of alignment at all, and I certainly don't want it to align with a mix of tabs and spaces
@mort@VZ I don't do c/c++ buy I think cindent if too opignated, and certainly influenced by the bonkers "gnu" style. You might not want to enable it and instead find a more reasonable plugin to handle that.
Hot C++ take: moved-from standard containers should be specified to work "as if newly default-constructed", not "in a valid but unspecified state"
Alternatively, we should embrace the unsafety and say that moved-from containers are in an "invalid state where the only safe operation is calling the destructor"
As it is, we get the (potential/small) overhead of making sure the container is in a valid state but not the convenience benefits of knowing what that state is
@mort I'm not sure, if I'd require that explicitly. Consider a struct, with only a POD int in it. If you require that moving leaves the moved-from in a default-constructed state, you would require from everybody that the move constructor first default-initializes its member and then swaps it with the moved-from member (if done with swapping).
If you do not default-initialize the member, the moved-from is still valid, but the value of the member is simply not specified.
I will never understand why #vscode defaults to not adding a newline at the end of the file
At least in UNIX-like systems, line feeds are line terminators. Many tools expect there to be a newline after the last line. Most text editors include a newline at the end of the file. VSCode's strange default causes lots of projects to end up with files without a final newline, and causes git churn where people add and remove trailing newlines. #microsoft#programming
USB-C is so cool, I get to spend time debugging why display out sometimes isn't working through this dock instead of doing boring things like getting work done
I think the order I have to do things is: 1) turn off the screen and unplug the dock, 2) plug in the dock, 3) turn on the screen
If I do things in any other order, or the laptop goes to sleep, the screen turns solid grey, and this state persists across laptop restarts and screen power cycling and dock disconnecting + reconnecting etc
@mort yeah I have similar issues. It's really annoying how unreliable this stuff is
I even had a supposedly compatible dock and it was such a pain I switched to using usb-c for one monitor, hdmi for another, and a simple USB hub for my other peripherals
It's not much, but I did a little #music today. I wanted to try out making music with the TR-808 drum machine sound, since I've always used more realistic-sounding drum samples. #lmms
Weird that #curl doesn't have an option for just sending arbitrary binary post data... even with --data-binary, curl adds a Content-Type: application/x-www-form-urlencoded header. This tripped me up just now, as this server I'm working against handles URL-encoded requests very differently from non-URL-encoded requests.
You can add -H 'Content-Type:' to remove the header, but it's weird that curl just adds that header even when it has no reason to think the payload is URL-encoded... #web
@bagder Yeah, I've used curl for many years to POST data to servers and it hasn't been an issue. However, this time I was making a server using a web server library which automatically parses the body itself instead of running my body handler callback if the Content-Type is application/x-www-urlencoded >_>
Took a while to debug, I was certain I'd used the library wrong. I hadn't imagined that curl would send a bogus Content-Type (nor did I expect the library to ignore my callback to be fair)
@mort it's not bogus since it is documented and curl has been doing this for 25 years. Also, if you think it "ignored" a callback, I suspect there's another misunderstanding in there...