as someone who worked at TR (now Refinitiv) and then Bloomberg, it's not even the data. it's IB. After IB it's the data. :)
2,248 karma · joined February 15, 2012
2. "easy enough" (this is a bit hyperbole, but i've done it) to take an iso and expose the playlists one wants as individual .m2ts files, and then everything recognizes it the same as mkv
did this using a fuse fs. drop all isos in a dir with a metadata file to list the playlists one wants exposed with how one wants them named, and the fuse fs turns each iso into a virtual directory populated by files named <name>.m2ts that corresponds to the playlist you wanted for it (work for seamless branching as well).
3. if saving space is so important to you, yes, none of this will apply, I still think the energy costs need to be factored in, to understand how much money one is saving / spending to accomplish that space savings. If one is going to be storing a digital iso backup of the discs they purchase (or borrow), what I listed in #2 is the best overall.
Is the $100-$200 savings worth the extra time spent (also computing/gpu electrical costs.
There's a reasonable argument that the cost in electricity would be measurable, perhaps small, but still measurable, if it's 1c per movie, not such a big deal, if its 50c a movie, one didn't actually save any money in practice. if one wants to software encode to get the best results, cost is going to be more than if one is ok with gpu encoding and just ok results from fixed encoders. (I would hazzard software encode at reasonable quality is going to be in the 25-50c cost if paying 25c a kwh)
If one lives in an area where electricity is cheap but storage is more expensive, the calculation is different.
Now, I'd note that there is one thing that storage being cheap can't directly solve. The ability to keep them online at a time (i.e. many computers are limited to the number of connected devices). In that world, one can argue that reducing that complexity also has value.
2) its very easy/straightforward to take a honeybee larve and raise it to be a queen (i.e. let it feed on royal jelly).
If you find animal research to be problematic, none of this changes anything. However, this did nothing to hurt honeybee colonies in north america.
This seems much more doable today than in the past as machines boot in moments. Switching from secure "xbox mode" to free form PC mode, would be barely a bump.
Now, I see one major difference, heterogenous vs homogenous hardware (and the associated drivers that come with that). In the xbox world, one is dealing with a very specific hardware platform and a single set of drivers. In the PC world (even in a trusted secure boot path), one is dealing with lots of different hardware and drivers that can all have their exploits. If users are more easily able to modify their PCs and set of drivers one, I'd imagine serious cheaters would gravitate to combinations they know they can exploit to break the secure/trusted boot boundary.
I wonder if there are other problems.
It shouldn't matter if a country's territory is occupied or not if nuclear weapons are the ultimate deterrent.
Ukraine has invaded Russia here and there during the war even though Russia has nuclear weapons.
The argument is weak, because in general the countries that have nuclear weapons wouldn't be invaded even if nuclear weapons did not exist.
"The courts just take issue with him naming his AI system as the sole author and himself as the copyright owner."
you can't claim a non human as the "author" and claim the material is copyrightable.
the "author" (not the AI) was trying to make a legal point/hack and the courts shot him down.
I'm not saying AI art should or shouldn't be copyrightable. One can argue the inputs into the AI generator are copyrightable, but if the output isn't deterministic translation of the input, its a different argument.
a compiler on the other hand is generally pretty deterministic. The non determinism that we see in output is usually non determinism (such as generated dates) in the code that it consumes.
However, they have 100 of them (so spend 4mil). so you might have to spend (if say 100k each). 10mil to protect your 10mil in property (and more if the interceptors cost more).
If on the other hand you can get the cost down to pennies (minus R&D costs), this is no longer part of the calculus.
when they wanted to create new chat apps, they had a choice. do we force all of our users to move to the new app or do we figure out a way to bridge the apps. They chose to force users to move.
The problem is, when you force people to move, you also give them the chance to leave and try new things. Instead of figuring out how to make the new chat app more valuable to users it was meant to appeal to by giving them access to google's entire chat userbase without forcing anything on those users, they killed their existing user base on the hope of forcing them to move to the new app. They didn't and now google's an afterthought in the chat space.
They did the same thing with google+ in general. They had a community of committed users sharing data with each other and commenting on stories on google reader. Instead of figuring out how to leverage that user base to contribute "content" to google+ and users that would prefer to use this new interface, and thereby make that new interface more valuable, they killed google reader in an attempt to force those users to migrate to google+. They didn't and went elsewhere.
Google has repeatedly made the mistake of forcing their users to migrate from what they were used to, and every time they do they open the gates for those users to migrate outside of google.
Facebook has learned this lesson relatively well. They don't force users to migrate to Instagram/facebook or whatsapp/messenger. In the Instagram / facebook case they seem to be improving the ability of users to use their Instagram account to add content to facebook (though not in the reverse). While in the whatsapp/messenger case, they haven't forced anyone to migrate, but they also haven't had any interoperability. One would think the apps would have even more value if they could communicate with each other.
In practice a DVD like PI/PO model would be the best for many people (protect the 1GB parts like you said with 5-10% redundancy, and then protect all 100 1GB parts together with 5-10% redundancy. the PI will repair as much as it can at the 1GB size, while the PO will be able to repair 1GB blocks that can't be repaired otherwise.
It be interesting if Par2 or something like it could implement it natively without people having to hack together their own one off solutions.
It only support 32k parts in total (or in reality that means in practice 16k parts of source and 16k parts of parity).
Lets take 100GB of data (relatively large, but within realm of reason of what someone might want to protect), that means each part will be ~6MB in size. But you're thinking you also created 100GB of parity data (6MB*16384 parity parts) so you're well protected. You're wrong.
Now lets say one has 20000 random bit error over that 100GB. Not a lot of errors, but guess what, par will not be able to protect you (assuming those 20000 errors are spread over > 16384 blocks it precalculated in the source). so at the simplest level , 20KB of errors can be unrecoverable.
par2 was created for usenet when a) the size of binaries being posted wasn't so large b) the size of article parts being posted wasn't so large c) the error model they were trying to protect was whole articles not coming through or equivalently having errors. In the olden days of usenet binary posting you would see many "part repost requests", that basically disappeared with par (then quickly par2) introduction. It fails badly with many other error models.
it seems conventional wisdom (for good or bad) would say 32" at 1440p isn't that great for productivity and one wants a full 4k monitor at that size for productivity use, and 8k at 85" would be about the same pixel density of 1440p at 32"
However, their usage accounting software wasn't great. I had it setup to reconnect if the connection dropped, and they didn't do a great job seeing this, so they accused me of using 2-3k hours during those 2 months (should be impossible if always coming from the same #) and sent me a large bill (for the hours used over 1500). They eventually gave in when I showed them it was impossible and they could validate that the calls were coming from the same line due to the connection dropping and being simple reconnections.