1,911 karma · joined August 28, 2018
If this investigation moves forward -- unlikely under a democratic government as we'll probably have -- one of the potential outcomes are better corporate firewalls.
If Google were broken up, a la baby bells, unusual activity on Youtube might no longer result in loss of email and phone service.
I think the downside of Google is this happens about 100x as often as other organizations.
Google security also cares about Google's security, not your security. Your odds of account compromise go way up dealing with Google.
The root issue is Google. This doesn't happen with most companies. This is specific to Google's culture, which treats customers as statistics. That comes out of how Google thought about search and ads, and doesn't work for anything else.
The secondary issue is being dependent on one party.
The reason people do cleanroom is to eliminate risk of liability, it's simple, and it's foolproof. You can't mess it up. It also eliminates other potential issues (like tortious interference with someone who signed an NDA).
Legally, it's overkill. It's like using a thermonuclear bomb to swat a fly.
If you're going up against Microsoft, overkill absolutely makes sense; you might be legally right, but it will take millions of dollars in legal fees to show that. Programmers are cheaper than lawyers.
In the general case, though, you can just rewrite the old code and be done with it. Yourself. Looking at the old code too, so long as you don't borrow it. You want to be a little bit careful since it's not just the literal words (you can break copyright on a novel if you rewrite the same plot in your own words; same thing with code), but "a little careful" suffices.
It's a bit harder to transform a piece of code into something non-infringing, rewriting section-by-section, but most lawyers say that's not impossible either.
(Of course, clearly, none of that happened in this case)
* competent ML engineer;
* competent at doing statistical analysis;
* competent at 3d graphics;
* competent at graph theory / SNA;
* competent at signal processing; or
* competent at control systems
is a few semesters, not a month. There is deep intuition behind the concepts, and it takes a lot of time to pick up. The core problem is there are no short-term gains. Dabbling in linear algebra is not a skillset which improves your employability, or broadens projects you can work on.
Being able to develop TensorFlow, optimize 3d rendering for NVidia, process images for Adobe, or design a control system for a robot IS an employable skillset, and makes for much more interesting work. Picking that up is why I'd send my kid to a school like CMU.
Similarly for precalc and calc. It's not hard to know what a derivative and integral is. There is mathematical depth to being able to do something interesting with that.
If college gets you that background, you can pick up Agile and test infrastructure on-the-job.
This seems like the sort of thing which could be adapted for amateur/DIY use.
It seems like you just need some hardware, which could be manufactured cheaply and easily, air-tight fabric, and a way of joining those.
I get the industrial / military / etc. uses, but I find the concept of anyone being able to build a temporary, usable structure in a custom configuration for a few hundred bucks a lot more interesting.
Still air is also a pretty good insulator, so if this were enclosed, it'd be a pretty good shelter even in colder climates.
1) Stuff I'd learn by reading Hacker News, after a few months
2) Stuff I'd learn on the job, after a few months
I'm not downplaying that it's important to know, but it's like converting a set of free blog posts into a $5000 university course.
Is that an efficient use of student time or money? Probably not. They're better off getting a summer internship, and getting paid to learn agile (and learning it better! working on an agile team will teach a lot more than listening to a lecture), or reading the anecdotes while procrastinating real homework, and posting in forums like this one.
It's okay that courses at a university do little to prepare people for some realities. Courses are designed to teach big-O, differential equations, database architectures, the math of machine learning, and similar sorts of things where there's enough theoretical depth that you CAN'T pick up elsewhere.
If a software engineer enters industry without knowing linear algebra, odds are they'll never be a data engineer in a serious ML project, or even more so, work on serious ML themselves.
TL;DR: Content looks useful, but it's an counterproductive use of tuition dollars and student time.
That makes me really happy.
I'll narrow my request to a suggestion for something easier (indeed, easy enough I can do a bit myself): more documentation and tutorials. I think I'll get on that (although on my own pages; I'm not ambitious enough this month to contribute upstream). I did a fair bit of searching at one point, and didn't find this stuff. Now, I can try to come up with good kids activities.
I will also mention: Most kids can do pretty advanced stuff, if introduced correctly. We've been wedded to a particular order of teaching math for a very long time, which places things like convolutions as late college-level math, and long division as late elementary. In fact, convolution is a lot easier than long division. That's true for a lot of "advanced" math.
There is a critical mass of people who simply won't use Google in a business-critical setting, and it's growing quickly. Now, that adds any GSuite office which relied on Google for working printers. Is that a lot? Probably not. Multiply that times each time this has happened before, and times the never of businesses wacked out-of-business by Google's automated algorithms, and at this point, I think it's quickly reaching the point where most teams have a Google horror story or two.
It's fine for purely transactional businesses (ones with zero startup/shutdown costs -- for example, one can arbitrage adwords and referral fees).
My guess is that at some point, Google will realize this, either from data or otherwise, and sunset GCE and related services, probably with very short notice, leaving many businesses hanging.
Short of giving a 10-year guarantee of keeping services running at specific cost and service levels, with real liability (not externalizing costs to customers again), I don't see how Google could address this.
* Integration with numpy/scipy/matplotlib/etc.
* Integration with Python Mode for Processing
* Integration with either the Arduino or the Micro:bit ecosystem
* Integration with Pygame Zero (so there are smooth, documented ways to transition -- low floor/high ceiling, rather than two modes of working)
* Eventually, integration and wrapping of OpenCV
In other words, Pygame would benefit from integrating with the broader ecosystem one might wish to use to teach kids to code. Writing games involves a lot of math, image processing, and similar, and 2020 computers are fast enough kids can do that without writing optimized assembly. It's nice if games can be physically embedded (Arduino/Micro:bit).
Right now, there's a collection of projects, but they don't play well together. The level of contortions one must go through to move a sprite from being a numpy array to an image in whatever library, to an image in another library, is well beyond what most kids (or even teachers) can handle.
1) I'm not ready to jump installed systems to arch right now.
2) Next system I install will probably try arch.
Thank you!
1) https://www.raspberrypi.org/documentation/installation/insta...
2) man fdisk
3) man mkfs
And so on. The /dev/sd_ is primary, with UUIDs as kind of an afterthought
It ought to be the other way around, with UUIDs as the primary, proper, canonical name and interface, and a legacy backwards-compatibility layer for /dev/sd_ devices. It's even reflected in the directory structure. Yes, I CAN list disk "by-uuid," label, id, partuuid, or path, but those are special cases with sd_ as canonical.
It's kinda retrokludged in there. I never said USB/etc. didn't work. Just that it wasn't architected for it.
Do you know if:
1) Zoom works? Linux has a blob which does.
2) OBS works? This is critical.
3) How is video support with ATI/Nvidia? Will my multimonitor setup break?
The other thing which scares me is the manual upgrade process. On my systems, I've done apt-get update/dist-upgrade for a quarter century now, with never an issue.
* My USB webcams wouldn't show up in a different order each time I reboot. This works fine under Windows and Mac.
* My monitor configuration wouldn't be hardcoded in my xorg config file, or swapped around manually with xrandr. I'd have a way to code up config options for whatever is plugged in, and if something unanticipated happens, it'd do something reasonable until I coded that config in too.
* I wouldn't need to reconfigure my drawing tablet to connect to the right monitor each time I plug it in.
* The system wouldn't get into an unrecoverable, unstable state with e.g. an unreliable USB cable.
.. and so on. It's designed for a fixed set of hardware, with layers on top of that to support hotswapping. I don't have "USB 4k Logitech Webcam" on the native level. I have /dev/video3. I then have layers to map names back.
Same thing with HDDs too, actually. I refer to them as /dev/sdc4, rather than by a GUID or name or similar. Layers with onions.
Part of that is working Bluetooth, power management, webcams, video conferencing, OBS, and similar. Historically, OpenBSD was behind Linux on working reliably.
Debian used to do this before:
1) It fell behind on hardware support, as laptops took over desktops; and
2) Ubuntu/Fedora started putting out massive numbers of half-baked technologies, and everything building atop those.
I switched to Ubuntu, without Gnome, but increasingly, things don't work without Ubuntu's UX, and snap shows a future I don't want to head down anymore.
I'll look into arch linux, as someone suggested.
* US is a common law jurisdiction, and indeed, pre-colonization UK courts sometimes act as precedent for post-revolution US courts.
* US courts come from colonial courts
If you'd like to read more:
https://en.wikipedia.org/wiki/History_of_the_American_legal_...
"Legal procedures in the 17th century were quite informal, with judges discussing issues directly with the people involved in the case."
"Colonial legislatures passed laws to fix the fees lawyers could charge for standardized procedures and maintain these fees relatively low. This often led some lawyers to handle a high volume of cases more speedily."
... and so on.
By the time the US formed, you had plenty of lawyers, but you had plenty of people representing themselves (and in cases above what would go into small claims).
The concept of statutory legal fees is a good one. It's present in a form in the German legal system. It's limited; you can pay more than statutory fees, but you can't recover more than statutory fees if you lose. That's still powerful. I know of a case where a big party PROBABLY owes a small party a few million dollars, but if they came out liable for opposing side's legal fees, they'd be bankrupt. And the litigation would cost a few years of their life.
And yes, cases were simpler, but that's as much a property of the unnecessary rising complexity of our legal system as of the cases. Modern cases shouldn't be so complex.
I gave it as an example of something which ran rather sophisticated theming/compositing/effects on hardware at least 2 orders of magnitude slower than today, and something which modern Ubuntu/Fedora struggle with.
I'd encourage you to compare the specs of the 3dfx Voodoo (the "magic dust") to even bottom-barrel integrated graphics of 2020.
What we're arguing is why everything is not fine.
SGIs ran VR, multiple displays, and very demanding apps in the nineties too. They did all sorts of wonky, complex, 3d input devices too. So did DEC Alphas. This is the stuff Unix was built for.
My claim is that nineties Linux was much closer to having the right architecture for it than 2020 Linux for this sort of stuff. The reinventions and onion layers didn't help; they hurt.
I think the only piece nineties Linux didn't anticipate was the level of hot-swapping hardware (USB, Bluetooth, displays, etc.), and the level of power management. Modern Linux never got that architected or integrated quite right, because it was built with hack upon hack upon kludge. It's split up in bizarre ways between kernel and user space which would be really tough to clean up right now.
Yes, we need a newer web browser, but that could run on old-school Linux/Unix just fine. Aside from that, there isn't anything wrong with nineties Linux which couldn't have been brought up to modern standards with a bit more discipline.
Someone decided ALSA (or OSS, it doesn't matter) was rough to deal with, so they build Pulse and JACK on top of it, rather than a modest expansion of ALSA. Someone didn't like the network layer, so they build a userspace wrapper, and someone didn't like that, so they wrapped it up in a GUI.
At the end of the day:
1) Everything is slow, requiring literally more than 100x the resources it once did.
2) Everything is complex, with layers upon layers, and text files with comments "This is managed by my hack. DO NOT EDIT THIS BY HAND. I keep the exact same data elsewhere, in my own config file, since I couldn't be bothered to read what's in the line below."
3) Everything is brittle and hard-to-understand. I knew how nineties Linux booted. Today, the logic is distributed among dozens of layers, mostly because people wanted to reinvent new things, rather than polishing/improving/fixing old ones. Different apps go for the wrong layer, and tutorials point to the wrong ones too.
Now Ubuntu is throwing its hands up at the mess, and building snap to hide all this under yet. another. layer.
As a footnote, ALSA was just about the last time this happened right, with it replacing OSS while maintaining compatibility.
I don't get why Wayland is slow, when Enlightenment was fast on machines with 32MB of RAM, a 3dfx Voodoo, a spinning HDD, and a 66MHz CPU...
Earlier lawyers had fees capped at fairly low levels. Money wasn't a thing since lawyers were fixed-price for a type of case, by legislation.
If Biden is talking about serious judicial reforms, simplifying the court system to where individuals can represent themselves, and capping legal fees seem like the ways to do it. He'd never do it, though; the democrats are in the pocket of the legal lobby.
That's not how the law works. Legally correct is much less pedantic than technically correct. The difference is that legally correct often takes millions of dollars to ascertain.
I use youtube-dl all the time, and never illegally. Most of the content is CC-licensed educational content, and the major use is working in contexts without guaranteed bandwidth.
"Great value for the price" isn't the same as "sturdy," though. I don't have anything from Ikea which I would describe as "made very well," and I'm under no illusions that it will outlast me, like my proper furniture.
With free software, if I waste a year tweaking something to figure out how to Do Things Right, that's okay. If I'm a downright a-hole about accepting commits (Hi Linus!), that's okay too.
It's different incentive structures.
From my perspective, Linux circa 1995 was just fine. If anything, Linux 2020 is a modest step backwards. I'd rather have long timelines and high reliability. That's not something commercial teams can sustain. People need to keep externally signalling productivity.
Ubuntu and Red Hat are a bit of a wildcard, since they take a hybrid model which seems to be dragging Linux down the path to look a lot like Windows 95, with layers of hairballs upon layers of hairballs. I'm not thrilled about that.
I'm more optimistic about motivations. Most people don't have time to sell (or even give away) something they bought for $200 now worth $30 on the second-hand market. If I could dispose of this stuff safely, freely, and easily, I definitely would.
Heck, if Ikea keeps this up, I bet there will be a third-hand market where people haul this junk away to Ikea, and resell vouchers/new furniture. That'd be awesome. If I could dump this stuff on the curb, and know it won't end up in a landfill, I'd totally do it.
To be in compliance with the license, you need to __substantively__ follow the provisions. If you and I sign a contract that I will build a house under terms carefully laid out in the contract, and I make a change from those terms which is not material and substantive (makes no difference to you), I'm not liable for anything. The kind of nits OP is pointing at would never fly in court.
From there, it isn't a question of "triggering provision" and being "liable." Liability is calculated in terms of damages. Damages aren't set to hurt people, but to make things right. If I sell you a defective car, damages are what it takes to fix or repair that car, not ten million dollars. If I use a different type of flooring building your house because the type you wanted was sold out, a court would rule on the difference in value; you can't just refuse to accept the house. This becomes really important in commercial law.
All of the example OP brings up, if they were in fact problems (and they're not), they would have damages of $0.00. There is no liability, so they're okay. That's how you interpret contracts. Lawyers read, write, and follow contracts with how they'll be interpreted in mind.
And from there, every other sentence is just technically wrong. E.g.: "Due to its nature, the AGPL is an EULA, not a free software copyleft license"
I could write a 30 page paper on the holes there, but at the core, what's missing is a basic understanding of how commercial law works. Without that common understanding, it's like trying to convince your grandma, who has never touched a computer before, about how Facebook's algorithms work. It's hard. It requires a common base of knowledge which OP doesn't have. At that point, you're better off advising people to either take a class in basic business law, or to talk to a lawyer.
Actually, a better analogy than Facebook might be data structures in git. Eben Moglen, who wrote the AGPL, is one of the more brilliant legal scholars alive today. That's much like a person who's never used a computer before trying to poke holes at Linus' hash DAG structure.
At some point, you either have to trust the competence of experts, or you have to educate yourself.
If I'm labeling pins and parts on a PCB, I'll take low-quality labels over no labels any day. If I'm labeling how wood fits together on a laser cut, I'll take it. If I'm making educational resources, quality almost doesn't matter.
If I could have a 1980-era printhead I could control, I could do a lot with it.
And if we had that, quality would improve with time. Look how many years it took 3d printers to be useful for anything practical. I expect if we started even with 1980-era inkjet quality, we'd get to nice in 5-10 years.
There's a massive growth curve too. If we could find a way to print on plastic, we could integrate this with a 3d printer and make decorated parts. I think this would be multiple stages of amateur R&D, but it would eventually happen (yes, I suspect someone will respond with all the technical issues why it can't work with current technology, ignoring all disclaimers -- I am aware this won't work right now).
I think of tons of other use cases.
I think the problem is as others have described. Making a printhead costs peanuts, but engineering one and NREs are astronomical. Ditto for paper handling, and many other parts of the printer. There used to be an printhead open enough for DIY (you could buy them in quantities of 1, and there was a spec sheet), but it's not sold anymore.
I guess when you say "has absolutely not been evaluated by people who should care," it's because you think anyone short of Yale isn't a real lawyer. Those jokers and clowns from Harvard....
You're trying to interpret a legal document like a computer reading a piece of code, and not even reading it correctly at that.