HNHacker News
TopNewBestAskShowJobs

gshulegaard

2,019 karma · joined March 3, 2016

submissionscomments
gshulegaard··on Use GNU Emacs
I had the same realization...so I took some bits of doomemacs/spacemacs and incorporated it into my personal emacs configuration. I am not great at maintaining my config or writing elisp in general, but feel free to reference my config if you wanted to take a stab at creating a doomemacs-like experience with your own configuration choices:

https://gitlab.com/gshulegaard/my-emacs

Disclaimer: This config is a bit perpetually dusty at this point, so I wouldn't copy it verbatim but instead use it as inspiration for some packages that might be worth looking into. JFYI anything that is from Marmelade might be worth avoiding as I suspect it is unmaintained given it's SSL cert expired in 2018. I just haven't gotten around to removing it from my config.

gshulegaard··on Go: Redefining For Loop Variable Semantics
I think you are confusing type of scoping (lexical/static, dynamic) with scoping levels.

Python has lexical scoping, but it does _not_ have block level scoping.

https://en.wikipedia.org/wiki/Scope_(computer_science)#Block...

Which, now that I have done enough reading I think crystallizes the confusing thing for others being highlighted here (for me). Depending on preference, the lack of block scoping can be surprising for someone. Which also explains my bias, I started with Python which probably plays a large part in why I find function level scoping without block scoping ergonomic.

gshulegaard··on Go: Redefining For Loop Variable Semantics
Well put. I too prefer the reasonability of lexical scoping. Although I must confess I am not well versed enough to quite grasp how what Python does _isn't_ conforming to lexical scope.

Since I was confused I did some internet searching and found this:

https://stackoverflow.com/questions/51604346/does-python-sco...

Which I think suggests the thing you are finding confusing isn't lexical scoping in Python, but rather the environment mutability.

Ultimately, I think I better understand what you are highlighting and can't say I entirely disagree. I just personally find how it is today ergonomic, but that could also just be bias as I am fairly comfortable in Python (warts and all).

gshulegaard··on Go: Redefining For Loop Variable Semantics
I found this interesting because I have never run into this before...and I thought that was rare (in relation to how comfortable I am with Python). That said, I personally think this is the right and intuitive outcome.

If we expand out the loop to be manual we would have a script like:

   functions = []
   
   # expanded loop
   i = 1
   functions.append(lambda: print(f"Hello {i}"))
   i = 2
   functions.append(lambda: print(f"Hello {i}"))
   ...
   i = 9
   functions.append(lambda: print(f"Hello {i}"))
Now at this point if we were to:

   print(f"Hello {i}")
What would the expected output be? I would posit that anything other than "Hello 9" would be wrong, both logically and intuitively.

So by extension a loop of effectively "print(f"Hello {i}")" 9 times should just print "Hello 9" 9 times IMO. Anything else is counter-intuitive and definitely surprising.

gshulegaard··on FCC asked to probe US carriers locking handsets to networks
> It's reasonable that the providers expect to have a way to enforce the contract.

No, no it is not. Contracts are legally binding and therefore enforcement should be done via legal means. This type of behavior is nothing short of vigilantism.

Beyond that, this type of behavior is anti-competitive. Carriers should compete on service and customer satisfaction, not how much of a margin they can eat to entice customers into contracts. This type of scheme naturally favors larger companies and acts as a way for industry incumbents to retain market market share.

gshulegaard··on Philly pays $30K to two 'courtesy' tow victims, but class-action suit continues
As someone relatively new to Philly, I am not at all surprised by the need for relocation towing. In the immediate Philadelphia metro area, but outside center city parking is extremely sparse. It's not uncommon for me to help squeeze neighbors into barely large enough parallel parking spots (by waving them in) at midnight. Some of these folks live more than 6 blocks away and purportedly were looking for parking after getting off work for an hour or longer.

Philadelphia is also the first place I have lived where parking in the center median of major thoroughfares is normal:

https://www.google.com/search?q=philadelphia+center+median+p...

Speaking of, I live a block off South Broad Street (most of the images in the link) and not too long ago there was a marathon that required clearing of that street of all parked cars for its entire length. It _was_ well communicated, well in advance but you can imagine that if parking is tight when the street side parking _and_ the center median is chalk full of cars, relocating is difficult. I don't know if any cars were relocation towed, but I know the night before the event I still saw some cars parked on Broad.

I still think there are communications issues, the city should have a way for owners to find their car. But I also think it's a bit more complex than your first take. Communication is hard and at the scale of Philadelphia I am not too surprised that there are cases where things can go awry between all the various bureaucracies you have to interact with in something like this. I also think it's pretty reasonable that the lawsuit is looking to force improvements, not do away with the system.

gshulegaard··on Shopify lets staff decide cash-stock pay mix as shares dive
Not quite. In the short term, perhaps, but I think the original comment was alluding to the fact that RSUs as an "investment" vehicle can have long term returns far greater than others.

Put another way, 200k in RSUs at an early stage company might be worth 100x or even more at IPO or acquisition years down the line. If you were to take that same 200k in cash and invest it in other ways you might be able to have the same return, but it's unlikely.

There are a lot of factors that affect this, but ultimately the potential return is something that start up employees can find attractive. These potential returns are also the underpinning financial motivator for Venture Capital.

gshulegaard··on Patent Trolls Inbound: Our First Lawsuit
I mean kind of. They have to go for people that have money to pay them off, but not enough to make fighting them worth it. Startup is kind of nebulous, but there is a difference between a 40+ million series B startup and a small business that would balk at $10k a year. I would guess the trolls go for more of the former than the latter.
gshulegaard··on How to choose the right Python concurrency API
Very salient point.

Having used both threading and various coroutine libraries (gevent prior to asyncio and asyncio more recently), I find coroutines easier to work with in modern versions of Python. So I don't find them superior strictly on performance; I also consider them more productive due to ease of use.

But I wouldn't disagree with someone choosing to use threads because they find them easier to grok than asyncio.

gshulegaard··on How to choose the right Python concurrency API
Right so the GIL improvements which (probably?) made it into 3.2 solves thrashing but introduces latency during "negotiation" for the GIL.

> What David illustrated is that GIL makes it harder to mix CPU- and IO-bound tasks in the same process. But coroutines are not the solution here. Solution is not to mix them.

Which I believe is my point and why I forwarded the personal notion that there really is only two acceptable concurrency models in Python. Coroutines solve cooperative scheduling for things that can be cooperatively scheduled. Threads _could_, but in Python specifically threads are strictly inferior as they have additional overhead by nature. In slightly different phrasing, Threads can be nearly or even acceptably equivalent to coroutines in performance, but they will never be better so long as Python has a GIL.

For everything else there is Multiprocessing (for example segmenting CPU processing from IO over separate processes).

gshulegaard··on How to choose the right Python concurrency API
I am not expert, and this might be dated information, but historically there is a "thrashing" introduced between the GIL and OS scheduled threads which has surprising performance implications.

David Beazley does a much better illustrating the nuances than I ever could:

https://www.youtube.com/watch?v=Obt-vMVdM8s

Including a wild phenomenon where a threaded Python program's performance can degrade by increasing number of CPU cores available to a system.

Coroutines avoid this by not requiring individual thread scheduling by the OS. So they effectively release the GIL like threads on IO but avoid OS level thread switching.

gshulegaard··on How to choose the right Python concurrency API
I am not sure when this article was written, but I really wouldn't recommend threads for even IO-bound tasks. Since threads don't escape the GIL the added contention with OS thread scheduling (context switching) is a performance overhead that coroutines (asyncio) don't have. I haven't benchmarked threads vs. coroutines for IO-bound tasks...but my gut feeling is coroutines are going to generally be better because of the lack of thread switching overhead.

So for me, there really are only 2 concurrency choices: coroutines or multiprocessing. And generally, if I find myself reaching for multiprocessing I seriously evaluate if the logic shouldn't be ported to a different language.

gshulegaard··on Atlassian is 20 years old and unprofitable
I think you might be confusing upselling and cross selling with network effects. Upsell is when you convince a customer to purchase additional service, like offering different tiers of subscriptions. Cross selling is where you sell adjacent services related to (and that possibly integrate with) the original service.

Network effects are where the direct value of a product grows simply because the number of users increases, causing the network itself to grow. The classic example are social networks. The more people on your social network, the more people are likely to join your network and less likely to join a smaller competitor. I am not sure there is anything in Atlassian’s product offering that quite fits that description, but that isn’t to say there isn’t plenty of upsell and cross sell opportunity as you describe.

gshulegaard··on Python 3.11 Performance Benchmarks Are Looking Fantastic
Ah yes, this is what I thought was the current state. I was curious if a GIL removal decision had been made that I had missed, but seems like it's still a soft "maybe":

https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0...

Edit: And to be fair, you can do "true" concurrency in Python you just have to eject to Multi-processing (with the tradeoffs that implies), so I didn't want to assume the comment was about GIL removal.

gshulegaard··on Python 3.11 Performance Benchmarks Are Looking Fantastic
Can you elaborate on what you mean by "actual concurrency in python soon"?
gshulegaard··on Ubiquiti is suing Brian Krebs for his reporting on their breach
Interesting, I have 3 edgerouters and UniFi AP which have been trucking for the better part of a decade. Can you point me in the direction for sources for their EoL issues?

I am about to double down on Ubiquiti as the networking backbone and security cameras for my new house, so I have a special interest in this currently.

gshulegaard··on Linux Developer Laptops: Dell's Precision 5500 series reigns supreme (2019)
Hmmm, I have a 5540 currently and don't have the problems you had (and I actually replaced the factory Ubuntu with PopOS after a year or two).

Although battery life is not great, but I am not sure that is as much a hardware issue as it is a software one. Although I am waiting on baited breath for AMD based hardware.

gshulegaard··on Python stands to lose its GIL, and gain a lot of speed
To be explicit, I was skeptical because I believed that GIL removal requires adding overhead for managing memory access. Having dug a bit deeper into it that seems confirmed. The proposed GIL removal strategy _is slower for single-threaded code_ like other solutions before it. It turns out the reported performance increase was the result of orthogonal performance improvements overshadowing the overhead of GIL removal.

Put another way, if the performance improvements were upstreamed without removing the GIL the resulting performance increase would be ~20% instead of just ~10%. Which is what Guido was getting at in the quote I cited. Assuming the benchmarks to be true for the moment, this means that removing the GIL on this PoC branch is a 10% performance hit to single-threaded workloads.

gshulegaard··on Python stands to lose its GIL, and gain a lot of speed
I feel like you aren't well informed on why removing the GIL results in a single-threaded performance hit. And while I think it's always nice to keep in mind the developer effort required, it's not the only cost as GIL removal has been done before (several times, even as far back as Python 1.5 [1]).

The crux of the issue (as I understand it) is that the GIL absolves the Python interpreter of downstream memory access control. You can replace the GIL with memory access controls of various strategies, but the overhead of that access control is just that: overhead. In a multi-threaded program the concurrency gains should outweigh that overhead, but in a single-threaded one it's just extra work that wasn't being done before.

Which brings us back to no free lunch. It turns out that the claim "10%" faster without the GIL is actually a result of Gross (GIL removal author) doing a multitude of unrelated performance improvements. These performance improvements increase performance enough that the performance of single-threaded no GIL code (with overhead) is ~10% higher than today. But as Guido pointed out, the core developers could upstream the performance improvements without the GIL removal:

> To be clear, Sam’s basic approach is a bit slower for single-threaded code, and he admits that. But to sweeten the pot he has also applied a bunch of unrelated speedups that make it faster in general, so that overall it’s always a win. But presumably we could upstream the latter easily, separately from the GIL-freeing part. [2]

[1] https://docs.python.org/3/faq/library.html#can-t-we-get-rid-...

[2] https://lwn.net/ml/python-dev/CAP7+vJJ1hzXiyDwVs6-eXed+DtodH...

gshulegaard··on Python stands to lose its GIL, and gain a lot of speed
Call me optimistically skeptical. I share similar reservations about GIL obsession with the original comment author, but if this is true:

> The overall effect of this change, and a number of others with it, actually boosts single-threaded performance slightly—by around 10%

Then it sounds like having the cake and eating it too (optimism). Although my experience keeps nagging at me with, "there is not such thing as a free lunch" (skepticism).

gshulegaard··on Things I’ve learned in my 20 years as a software engineer
I had the same thought process.
gshulegaard··on Why we spent the last month eliminating PostgreSQL subtransactions
Every once in awhile I find an article that is so well written I feel like it walks me through a complex technical situation like a layman while also expanding my understanding of a tool I use everyday in a meaningful way. This is definitely one of those and I just want thank the author(s) for taking the time to write this up. It was interesting and enlightening.
gshulegaard··on OnlyFans to block sexually explicit videos starting in October
This is a common misconception (I blame American politics). In _perfect competition_ this would hold true; however a _free_ market is not guaranteed to be competitive, much less close to _perfect_ competition.
gshulegaard··on Using PostgreSQL as a Data Warehouse
I am not sure I agree with the general idea that Postgres can't or even--albeit a bit less strongly--that it is hard to scale. Even in 2008 people were running petabyte-scale warehouses using Postgres:

https://www.toolbox.com/tech/data-management/blogs/2-petabyt...

Since 2008 improvements in parallel query execution (and numerous other improvements) in the core project plus the availability of forks/extensions which abstract and/or modify various bits for improving scalability (see Citus and Timescale) it's never been easier to scale Postgres to some truly staggering heights.

While I wouldn't want to speak in absolutes, there are very few applications where I think Postgres wouldn't be a viable choice as a data warehouse.

Emphasis on warehouse as I wouldn't want to suggest Postgres as an ideal candidate to be a data lake. The difference between them for me being whether or not the data is structured/processed. Similar in definition to this article:

https://medium.com/@distillerytech/data-warehouse-vs-data-la...

Personally, I have experience scaling core PostgreSQL (9.4) to handle ingestion of monitoring data for web servers to the tune of 2-3 terabytes a day. Not the grandest of scales, but enough to have seen a few bumps along the way...and, for what it's worth, I think it is surprisingly easy to scale.

I wouldn't want to sign up to scale Postgres to handle exabyte data loads, but single digit petabytes? Sure.

https://techcommunity.microsoft.com/t5/azure-database-for-po...

And at petabyte-scale, I personally think it qualifies as a data warehouse.

gshulegaard··on Using PostgreSQL as a Data Warehouse
I would have to dig more into specifics of your use case but my gut reaction is yes, it would be better.

I do not have specific experience with TimescaleDB, but I have some experience scaling PostgreSQL directly and with Citus (which is similar, but not the same). But depending on the nuances of your use case, I can envision a number of scaling strategies in vanilla Postgres to handle your use case. A lot of what Timescale and Citus does is abstract some of those strategies and extend them. Which is just a vague way of me saying: I think I could probably come up with a scheme in vanilla Postgres to support your use case, and since Timescale/Citus makes those strategies even easier/better I am fairly confident they would also handle that use case.

As an example I currently have a table in my current Citus schema that is sharded by column hash (e.g. "type" enumerator) and further partitioned by time. The first part (hash based sharding) seems possibly sufficient for your use case.

Beyond the most simple applications in that domain though, there are more exotic options available to both Timescale and Citus that could come into play. For example, I know Citus recently incorporated some of their work on the cstore_fdw into Citus "natively" to allow columnar storage tables directly:

https://www.citusdata.com/blog/2021/03/05/citus-10-release-o...

gshulegaard··on U.S. Labor Secretary throws support behind classifying gig workers as employees
I think you might be more in agreement with the original comment than how I interpreted your comment.

Personally, I think OP is calling out that most of the issues with current Uber (and similar companies) is the asymmetry of information. Only Uber knows where all the riders are, what they are paying, and where they are going. They also are the only ones that know where all the drivers are and how much they are expecting to be paid. This information asymmetry allows them to expose just enough information to both rider and driver to facilitate the outcome Uber wants. In my mind, when Uber (or anyone else) starts controlling the flow of information they cease to be simply a platform/market place.

The majority of issues (in my mind) resolve themselves when this data asymmetry is removed. Driver's have more freedom of choice if they can see all available fares rather than just a yes/no prompt on an individual basis, for example.

I also think there is far more gray area to these types of employment relationships that is generally acceptable when it comes to things like how you do the job, how you dress, etc. For example, if you are an independent delivery driver but enter into a contract with FedEx it is acceptable for FedEx to stipulate that you wear a FedEx uniform while delivering FedEx parcels. If you don't find that stipulation acceptable, you can decline the contract. Likewise, if FedEx discovers you aren't following contractual obligations they can terminate the relationship.

gshulegaard··on Where did the other dollar go, Jeff?
Hmmm! Well thank you for your response! I think that I find myself far more in agreement with this additional detail.

> It's not particularly interesting for $450 dollars to change hands in a vacuum; the transaction is given meaning because it represents something about the painting that was created and sold.

And this:

> The biggest intended takeaway of my post wasn't even that the dollars being discussed don't correspond to anything, it's that they correspond to a bunch of different types of thing that don't sum together cleanly.

In particular resonate with me. This intended meaning I (personally) lost in the economic semantics. Hopefully my comment about not wanting to paint Amazon as some altruistic entity alluded to my own personal nuanced feelings here, but to expand on something that I think is more aligned with the point you were trying to make:

There is no doubt in my mind that the employment opportunities generated by Amazon provide value to the economy at large, but that doesn't mean that the value is as great as it could, would, or even should be. I think that there is a fair argument to be made that the labor practices at Amazon strays into labor exploitation and they only can do so since they benefit from an non-competitive market dynamic. And that bigger picture is potentially one of the bigger pieces of context which isn't captured by a simple payroll figure.

gshulegaard··on Where did the other dollar go, Jeff?
This is an interesting article but it starts off on the wrong foot for me:

> This is patently ridiculous. Every single dollar of compensation paid out is done transactionally: it is used to purchase labor. In a typical transaction, no value is created.

This, as I understand it in a limited fashion, is not true. There is a concept of the velocity of money in which more value than the initial transaction is created:

https://en.wikipedia.org/wiki/Velocity_of_money

This is, in part I believe, why a nation's GDP can exceed it's nominal cash in circulation. In particular, the Great Depression was a period of low monetary velocity and yet staggering inflation; the term "stagflation" (stagnation + inflation) was coined to describe this phenomena.

https://en.wikipedia.org/wiki/Stagflation

Which in turn calls into question the following criticism:

> But however you look at it, taking full credit for every single dollar of compensation as value creation— as if Amazon, and not the US Mint, created those dollars, and as if the many, many millions of hours of labor consumed by the company in return were valueless— is a ghastly overstatement.

While I would never want to make it seem like Amazon is some sort of altruistic entity who simply makes the lives of those on it's payroll better, it is not as ghastly an overstatement as claimed. There is a reason recovery from the Great Depression involved job creation through The New Deal and war-time production and not simply the US Treasury "creating those dollars".

These kinds of economic inconsistencies continue throughout the post. In particular there seems to be a pervasive belief that Monetary Supply is finite/controlled by the Federal Reserve and therefore cannot be used to measure value creation:

> But the value you created isn’t the money. The money already existed and was floating around the economy long before you picked up the brush. The value you created was in the art, which is now in someone else’s hands.

This is a false premise. Dollar-value estimations of created value like GDP are often imperfect measurements, but they do exist; furthermore, they often exceed the nominal amount of financial notes in circulation. There also certainly is additional value that isn't captured by a dollar value, such as the value an owner places on a created piece of art, but that is not the same as no monetary value created.

I don't know who the author is, but even my limited grasp of economic theory makes me question the main thrust of their arguments. But I also know my grasp of economic theory is threadbare at best, so perhaps I am completely off base.

gshulegaard··on Robinhood Files S-1
I am not well versed in the financial services industry but this article seemed to offer at least a plausible explanation for why Robinhood (and other capital limited brokers) stopped buys on GME specifically:

https://stu2b50.dev/posts/why-robinhood-d3580b

I want to be upfront in that I can't verify the accuracy of this article, and I still look askance at Robinhood personally; however, it did pique my interest in keeping an eye out for further analyses of the incident as more details emerge. And it seems like there is plausibility to Robinhood's claims that they had to halt buys.

And...on the face of it, I am all for regulation that places risk management requirements on financial firms.

gshulegaard··on System76 Developing “Cosmic” Desktop Environment
Last Galago I purchased came with a power brick but also supported usb-c power delivery.
← PreviousPage 2 of 19Next →