1,988 karma · joined May 22, 2011
I thought I had read when the M1 came out that they had memory compression turned on by default but I'm not an Apple user.
I've observed this same behavior on modern operating systems with big rsync jobs and spinning drives. If you have lots of small files then reading the metadata and directory structure takes a while but fits in the cache, so a second rsync will catch up very quickly to the first.
SQL's NULL is far more useful though, since NULL != NULL. That lets you do things like join two tables with a column and not have the NULLs match.
Consider, for example:
select * from users where id = null;
It's also really nice for non-ID, non-reference fields to represent N/A. For example, user.birthdate can be NULL if the birthdate is not known.
SQL also lets you choose when you want NULL to be allowed for a column, so it's less likely to be a gotcha.
I personally agree with the decision. The discussion generated is still valuable even when I can't read the whole article. A lot of the paywalled sites are generating content that's more valuable than the average blog, which is why they're able to survive behind a paywall to begin with.
Caps discourage people from using too much and making the network slow for everyone and/or very expensive to run. It'd be great if, instead, bandwidth was prioritized based on usage each month. So the really heavy users that cause problems for everyone else will run slowly during the day but still can be fast at night.
Ideally there would be a way to mark streams as low-priority in a way that didn't count against your quota, that could be used automatically by backup software and other cases.
Another possible system which seems fair to me would be to give each user a guaranteed 1/N of the bandwidth. If there's any unused, then split it equally among those that are using it. In practice an ISP needs to have enough capacity to support streaming during the peak hours, so that'd keep the 1/N value reasonable. For example, if a local ISP offers 1 gbps connections to 200 customers and has them sharing a 10 gbps upstream connection to the wider internet, each would have a guaranteed 50 mbps, with ability to burst to all 1 gbps most of the time. That's plenty fast for streaming from several devices per household. If someone needs faster guaranteed speed, they can pay extra for more bandwidth shares.
The copyright on the code, on the other hand, would definitely be copyrighted and would need a clean-room implementation, as you said. The community could pool its resources and do it once, and license it under the AGPL to keep it and further improvements available to everyone.
[1]: https://en.wikipedia.org/wiki/Malapropism [2]: https://old.reddit.com/r/BoneAppleTea.
foo = if bar
1
else
2
endhttp://www.noiseprotocol.org/noise.html#zero-rtt-and-noise-p...
It looks like Windows also has memory compression.
I believe that OS X has memory compression turned on by default.
Ruby inherits the Perl philosophy of "There's more than one way to do it". Compare with Python, and its "There should be one — and preferably only one — obvious way to do it."
It's true that it makes the compiler less elegant, but Ruby optimizes for the programmer at the expense of the compiler.
Depending on the application, you could lower the bitrate significantly during times of low motion or low detail (such as at night). You could also drop the framerate.
I've found that when the scene is static, without panning, and no wind blowing leaves on trees, you can compress really well. I have a Wyze outdoor cam looking at the front yard that does 1080p at a little less than 1 mbps.
My friend has an off-grid cabin and his solar panels were easy to size for all other energy needs during winter by having them installed angled towards the winter sun position.
He does have a small generator just in case there is a particularly bad winter storm, but even in that circumstance it just has to run long enough to charge his batteries, so fuel consumption is minimal.
https://pcpartpicker.com/products/internal-hard-drive/#sort=...
Also be sure to check external drives. Sometimes it's cheaper to buy one of those and then discard the enclosure.
https://pcpartpicker.com/products/external-hard-drive/#sort=...
https://en.wikipedia.org/wiki/Generic_trademark#Avoiding_gen...
Copyright doesn't work the same way. You can selectively enforce it, at your discretion, without risking loss of the copyright.
We split into four teams, with one providing power, one providing ammo, one building defenses, and the rest just running around trying to help out where we needed it the most.
There was a ton of potential. I had to keep adjusting the difficulty as the match went on to keep us alive and then to finish us off when we were running out of time.
I'd love a multiplayer coop game like this but with the potential to have fifty or a hundred players. Right now the office plays CS:GO once a week, with the settings changed to allow max players, but it still caps at thirty. CS:GO is hard for new employees to get in to so I'd love something where everyone has fun. We also did TF2 for a while, which was better because the newbies could be medics and still feel like they were contributing, but the hard-core player base loved the challenge of CS:GO.
I've been using it since March with no complaints. It'd be great if manufacturers could standardize on something like this so that the port could be flush.
Seems like it'd sort of be like the rocket equation, but more forgiving.
I've found that the right level of abstraction is the one that saves time and effort and duplication now, for the features you're currently shipping. If you're thinking about hypothetical new features that aren't even on the roadmap then you've gone too far.
As an example, say your embedded program needs to load images, and your standard library only supports raw BMP files. BMP images are going to work great for the time being, since the art team can supply them that way. By all means, add abstraction method around the library method called "load_image" so that you don't have to refactor a million places to replace that library. It'll give you a great place to add error handling, logging, etc.
Beyond a single method to add a point of attack, don't go beyond that and spend the time to add a JPEG and PNG library, don't add support for high bit-depth images, or for grayscale images, or CMYK images. Don't add an abstraction that'll someday be able to load the Nth frame from a video file. Perhaps throw an exception for unusual input, but beyond that don't waste your time.
In my experience having simple, direct code makes it easier to refactor in the future when the need arises. Having too much abstraction or future proofing gets in the way because the future inevitably will bring different changes than what you were expecting.
In addition to making it easier to do security updates in situations like log4j, it'd also make it easy to comply with LGPL license terms.
For that matter, at a certain point your car insurance might give you a big discount to have one installed and subsidize the installation and hardware costs. There's a profit motive for the first company that does so, being able to offer much cheaper rates while still paying out far less for at-fault collisions.