even the non-cheap recorders produce a huge quality loss. It would be slightly easier, but if you're considering archiving something, why not do it as good as possible
It's not only that - the bag prices mess with price comparison web sites so much, that it's impossible to find the best deal. Win-Win for the airlines.
VHS is indeed horribble, if watched on today's TVs and wasn't that great back then. European PAL was a bit better than NTSC. And, while it's full of noise, it doesn't have the smear of digital noise reduction.
Scorsese grew up with this TV resolution and I'm sure he would have preferred high quality for things we cared about, but for day-to-day use, having VHS was fine. (If he really cared, he could have gotten a betamax recorder or a super-VHS recorder to record off the TV)
I'm pretty sure that he'll stream better copies - but for those not available, having a noisy VHS is great. And with streaming/digital "sales" you never know which films you're going to lose next...
Yes but for your own projects you could have a first page with a "no JS" div and attach a HTMX load request. That's how I did my first HTMX project and it works well informing you to turn on JS.
The other two downsides are: Some people may chose not to have their email account on the phone. Personally I don't want to carry around access to my main email at all times (the same goes for access to my main bank account, BTW.)
Also, email delivery sometimes takes a very long time, it can be minutes, if you rely on email forwarding to protect your main email address.
My situation exactly. We're sharing a 4 screen account with 3 friends and no-one even watches netflix every month - we just liked the idea of having access, in case we want to watch something. We already decided, when netflix doesn't allow low-use sharing any more, we'll just cancel and forget about it.
There's a big difference between a private copy for your own enjoyment and redistributing that on a larger scale. The first one is consuming something you were not meant to consume, with little or no cost to the rights owners. The second on is giving away something that someone else had substantial costs to produce.
In my mind it's fair game to record and watch anything, if it's an unencrypted, freely available broadcast somewhere (local laws here back me up) - That includes the use of VPNs to access it. Sports broadcasters know this and make the use of VPNs quite hard, still if you get it to work, good for you. That includes other sneaky trickery like VPNing into Switzerland, where rebroadcasting other countries' FTA TV is legal, if you can receive them there (e.g. all of the UK's FTA TV) or setting up a remote controlled TV receiver in the country for you own use.
Making these streams available publicly is a different game. Depending on where you live, passing on streams privately again may be OK - for example the country I live in allows passing on recordings to a handfull of friends.
If at any time during the chain from the broadcast to you there's a need to break an encryption to make this possible: No fair game, pirate!
If the ad revenue isn't measured in terms of the consumption on the pirate streams then it's not ad revenue. Advertisers don't pay for eyeballs they can't quantify.
If content is consumed via an illegal streaming site then it's potentially hurting revenues elsewhere.
Assuming those eyeballs would ever hit a legal streaming site.
By the time the content airs, the advertising money's mostly been made and traded already. In the terrestrial broadcasting world -- this is most definitely the case.
Try the travel/event booking business (where I'm in) - and no, people don't dump their mistakes on the next guy here - to the contrary, the "hacky" Python solutions are supported for years and teams stay for decades (allthough a decade ago we had not discovered how great Python was)
What business owners actually don't like at all is how long is takes traditional software development to actually solve problems - which then don't really fit the business after wasting a few years of ressources... and the dumping and running away is worse in Java and other compiled software. With Python you can at least read the source in production if the team ran away...
> the dumping and running away is worse in Java and other compiled software. With Python you can at least read the source in production if the team ran away...
Java (and dotnet, the two big "VM" languages) is somewhat of a strange example for that; JVM bytecode is surprisingly stable and reverse engineering is reasonably easy unless the code was purposely obfuscated - a bad sign on any language anyways.
If you're dealing in areas with short time limits then Python is great,
because you can't sell a ticket for a ship that has sailed.
And I've seen "the right way" which, again, depending on the business may
result in a well designed product that is not what's actually needed (because
people are really bad at defining what they want)
What's brilliant with Python compared to other hacky solutions that it
does support test, type hints, version control and other things. It just
doesn't force you to work that way. But if you want to write stable, maintainable
code, you can do it.
That means you can write your code without types and add them later.
Or add tests later once your prototype was been accepted. Or whenever something
goes wrong in production, fix it and then write a test against that.
Oh and I totally agree you should certainly try to "do things the right way",
if the business allows it.
It is hard to believe that Python is objectively that much more productive than other languages. I know Python moderately well (with much more real world experience in C#). I like Python very much but I don't think it is significantly more productive than C#.
This. C#, Java or even newcomers such as Kotlin/Go are even in the same ballpark due to the REPL/Jupyter alone. Let alone when you consider the ecosystem
If you are in a lab (natural science lab) or anywhere close to data, I bet you it is much more productive, even more so when you have to factor in that the code might be exposed to non-technical individuals.
reply