Yes, I remember Macrovision, and it's designed to futz with the automatic gain control of an average VCR recorder. Screwing with a VCR is substantially easier than screwing with off-the-shelf audio recorders because an audio recorder doesn't require any kind of synchronization signals.
ALL audio on smart phones is digital. They could DRM the headphone jack fairly trivially if they wanted to.
No, they couldn't. It's an analog signal at the jack, and a DRMed digital or scrambled analog signal would sound like noise through any traditional set of headphones.
It is astounding that this cultural flaw is found in every development group.
Not *every* group. A couple of years ago, I worked with a company where Development and QA actually looked at themselves as a partnership, and anything that came back marked broken from QA was looked at quite carefully and generally considered a failure on Dev's part. Even if we couldn't reproduce QA's bug right away, we still took quite a bit of time working with them trying to get it to show up again, and more than once took a snapshot of QA's VM in order to see what was different from our own system that might have triggered the bug.
I wouldn't say it's more advanced, just different. As another poster pointed out, different systems are called for when dealing with different volumes. Picking a dozen or so of a given item per day isn't the same as when it's a quarter-million of that item and the item is perishable, which requires a thorough design to prevent inventory from ever becoming stale. There are also a lot of other factors to consider, particularly in a mixed man/machine environment. What I discussed is a tiny, tiny part of the overall system.
The difference is that the Kiva robots effectively fit the niche where there are a large number of skus and small number of picks per sku per day.
True. The situation I have experience with is the other way around, where there are about 10,000 or so SKUs, and a few dozen of them get hundreds of thousands of picks per day. It's also different in that it's integrated with the production line, which offers both advantages and disadvantages.
I've seen automated warehouses with huge industrial cranes moving 500 pound drums and tiny little pill box pickers.
Those cranes are *fast* too. My experience is mostly with with HK (now Dematic) systems - it's cool as hell watching one of those 110-foot tall monsters running up and down the aisles.
If you don't know about these robots, BTW, they're quite clever. It's a shame among all these overpriced social media startup acquisitions that Kiva wasn't worth a lot more. Rather that getting hung up on the problem no one has solved yet (picking the part from the bin on the shelf reliably and cheaply), they built a robot to move the whole shelf to a central locations where the humans do the rest. They solved a problem that was practical to solve, and it made a real difference to efficiency.
That problem was actually solved some time ago - for years, Frito-Lay's bigger plants have had automated cranes to grab pallets from the shelves in 10-story warehouses, deposit them into a ground-level circulation conveyor where they're picked up by automated forklifts, then brought to the buffer areas where they're de-palletized and small robots then run the pick boxes to the appropriate place on the picking lines, and the shipping boxes are routed via conveyor automatically to the appropriate loading dock for deadloaded (non-palletized) bulk shipments. For palletized loads, the fork trucks are sent directly to the loading dock. Not all of their plants have the robot forklifts, and in the fully-automated plants they still have man-driven lifts, but even where the manual lifts are still in use they've seen *huge* efficiency gains with the system. The tricky part there is staging the inventory and product flow such that the oldest product always ships first. They're also starting to implement automated loading for the trucks even though an experienced loader is scary-fast.
The developers always get pissed off when I remind them that I don't get bonuses and I'm not obligated to care about their bonuses. Most of the inevitable delays come from them trying to get their bonuses instead of fixing the problems in their code.
Maybe the bonuses should be tied to code quality instead of schedule, or some combination of the two.
I much prefer working on low-level stuff like that myself, partly because it's a very stable world as you observed. I find it much more rewarding working in a resource-constrained environment and writing software that actually "does stuff", and for me, software is the most fun to work on when an oscilloscope or logic analyzer is necessary to debug your code. I too hope that web development reaches some kind of maturity, but I'm not holding out a lot of hope because so many web devs seem hell-bent on repeating the mistakes of the past and figuring out new and exciting ways of doing exactly the same thing. So much time is spent chasing current UI trends and figuring out workarounds for the latest browser issues, and that's just not something I enjoy.
The sad fact is that in our modern world you need to be fluent in not just a couple of programming languages, but also a whole body of other tools and toolkits in order to write interesting applications. That is a formidable barrier to entry that we aren't doing a very good job of solving.
Partly because popular toolkits or frameworks are a constantly moving target that have to be relearned every couple of years, particularly in the web world.
Which is part of the reason I replaced the suspension arms with aftermarket parts when it came time to replace the ball joints in my truck. Now everything is greaseable.:-D
The Moog parts I've used have been pretty good, but I usually prefer Timken if they're available. I've had to work on machines in a few Timken factories, and they really do seem to give a damn about quality.
How about the fact that he has been driving it ignoring the "thunk Thunk" noises for 5,000-10,000 miles? If a ball joint is failing it thunks. They guy ignored it for months.
I'm wondering about this as well. Short of a truly random catastrophic failure, ball joints (and most suspension components in general) give plenty of warning when there are problems. I'm no Tesla fanboy by any means, but any marginally attentive driver should have noticed handling issues well in advance of the failure. Rusty ball joints would have been making all kinds of noise and grinding sensations long before then.
Same for my poor abused 2002 GMC Sierra pickup with 135K miles. Coincidentally, I replaced the ball joints last November at about 125K miles (all four control arms, actually, because why not if you're already going to be in there), and the front wheel hubs in February (which took all of 15 minutes per side). It's been a remarkably trouble-free vehicle, all things considered.
I'm also wondering how you drive a car long enough for a ball joint to break without noticing handling problems long before.
It's not really a scam - patents forbid even the mere use of a patented invention without a license. I agree that it's a crappy way to do business, but it's completely legal.
Comcast has to supply an enormous back-end with many peering contracts, many interconnects, and much more hardware.
So does Level3, Cogent, and every other provider. I pay $29/month for a dedicated server with unlimited bandwidth on a 100 Mbit port, and in addition to bandwidth and the machine itself, my provider is paying rent for the cage in the DC, power, UPS, staffing, and all kinds of other expenses. Providers like 100TB.com offer much better deals than that and still manage to turn a profit. Cogent bandwidth by itself is often less than $1.00/MBit/month with a 1 Gbit commit, although it's more like $3-4 for better providers. Owning the equipment, I'm sure Comcast's cost is much less.
As was duly explained to the more recent employees, Lockdown was a state of war that dated to Facebook’s earliest days, when no one could leave the building while the company confronted some threat, either competitive or technical.
"I can't leave the building? Well, here's my badge. Fuck you."
Well, I never had any problems with AmigaBASIC, and released a shareware editor for the Yamaha DX-7 synth written in it. It didn't give you easy access to the system libraries, but it wasn't intended to be a professional development environment. AmigaBASIC wasn't "dumped" - it was still being distributed in 1.3, and ARexx was a higher-level scripting/macro language, not a general purpose programming language.
The point remains that your claim that the Amiga didn't have a working programming language available is provably false. Being unable to use those languages doesn't mean they didn't exist.
an Amiga that had no working programing language available
Sure there were - the Amiga originally came with Metacomco's ABasic - it wasn't great, but it was functional, and Metacomco also had a decent macro assembler available when the Amiga came out. When AmigaDOS 1.2 came out, they switched to Microsoft's AmigaBASIC. The Lattice and Manx C compilers came a little bit later.
Still have my A1000, the Manx compiler, the Metacomco assembler, and the RKMs.:-D
I was forced to take a semester of Latin in high school. I would never ever have taken that willingly, but having gone through it I can see that in another life I might have pursued linguistics. Who knew?
I only took Latin in my senior year of high school, but I really enjoyed it. My teacher was actress Eileen Brennan's sister (looked just like her), and had gone through a bad divorce and would teach us all kinds of hilariously abusive phrases. Sadly, I remember almost none of it but I wish I had taken more foreign language classes earlier.
Slashdot Mirror
Yes, I remember Macrovision, and it's designed to futz with the automatic gain control of an average VCR recorder. Screwing with a VCR is substantially easier than screwing with off-the-shelf audio recorders because an audio recorder doesn't require any kind of synchronization signals.
ALL audio on smart phones is digital. They could DRM the headphone jack fairly trivially if they wanted to.
No, they couldn't. It's an analog signal at the jack, and a DRMed digital or scrambled analog signal would sound like noise through any traditional set of headphones.
I've used both token ring and Ethernet attached DOS machines.
Don't forget ARCnet!
It is astounding that this cultural flaw is found in every development group.
Not *every* group. A couple of years ago, I worked with a company where Development and QA actually looked at themselves as a partnership, and anything that came back marked broken from QA was looked at quite carefully and generally considered a failure on Dev's part. Even if we couldn't reproduce QA's bug right away, we still took quite a bit of time working with them trying to get it to show up again, and more than once took a snapshot of QA's VM in order to see what was different from our own system that might have triggered the bug.
I wouldn't say it's more advanced, just different. As another poster pointed out, different systems are called for when dealing with different volumes. Picking a dozen or so of a given item per day isn't the same as when it's a quarter-million of that item and the item is perishable, which requires a thorough design to prevent inventory from ever becoming stale. There are also a lot of other factors to consider, particularly in a mixed man/machine environment. What I discussed is a tiny, tiny part of the overall system.
The difference is that the Kiva robots effectively fit the niche where there are a large number of skus and small number of picks per sku per day.
True. The situation I have experience with is the other way around, where there are about 10,000 or so SKUs, and a few dozen of them get hundreds of thousands of picks per day. It's also different in that it's integrated with the production line, which offers both advantages and disadvantages.
I've seen automated warehouses with huge industrial cranes moving 500 pound drums and tiny little pill box pickers.
Those cranes are *fast* too. My experience is mostly with with HK (now Dematic) systems - it's cool as hell watching one of those 110-foot tall monsters running up and down the aisles.
If you don't know about these robots, BTW, they're quite clever. It's a shame among all these overpriced social media startup acquisitions that Kiva wasn't worth a lot more. Rather that getting hung up on the problem no one has solved yet (picking the part from the bin on the shelf reliably and cheaply), they built a robot to move the whole shelf to a central locations where the humans do the rest. They solved a problem that was practical to solve, and it made a real difference to efficiency.
That problem was actually solved some time ago - for years, Frito-Lay's bigger plants have had automated cranes to grab pallets from the shelves in 10-story warehouses, deposit them into a ground-level circulation conveyor where they're picked up by automated forklifts, then brought to the buffer areas where they're de-palletized and small robots then run the pick boxes to the appropriate place on the picking lines, and the shipping boxes are routed via conveyor automatically to the appropriate loading dock for deadloaded (non-palletized) bulk shipments. For palletized loads, the fork trucks are sent directly to the loading dock. Not all of their plants have the robot forklifts, and in the fully-automated plants they still have man-driven lifts, but even where the manual lifts are still in use they've seen *huge* efficiency gains with the system. The tricky part there is staging the inventory and product flow such that the oldest product always ships first. They're also starting to implement automated loading for the trucks even though an experienced loader is scary-fast.
They may find they have less and less "product" to offer if they continue down this road.
The developers always get pissed off when I remind them that I don't get bonuses and I'm not obligated to care about their bonuses. Most of the inevitable delays come from them trying to get their bonuses instead of fixing the problems in their code.
Maybe the bonuses should be tied to code quality instead of schedule, or some combination of the two.
I much prefer working on low-level stuff like that myself, partly because it's a very stable world as you observed. I find it much more rewarding working in a resource-constrained environment and writing software that actually "does stuff", and for me, software is the most fun to work on when an oscilloscope or logic analyzer is necessary to debug your code. I too hope that web development reaches some kind of maturity, but I'm not holding out a lot of hope because so many web devs seem hell-bent on repeating the mistakes of the past and figuring out new and exciting ways of doing exactly the same thing. So much time is spent chasing current UI trends and figuring out workarounds for the latest browser issues, and that's just not something I enjoy.
The sad fact is that in our modern world you need to be fluent in not just a couple of programming languages, but also a whole body of other tools and toolkits in order to write interesting applications. That is a formidable barrier to entry that we aren't doing a very good job of solving.
Partly because popular toolkits or frameworks are a constantly moving target that have to be relearned every couple of years, particularly in the web world.
Which is part of the reason I replaced the suspension arms with aftermarket parts when it came time to replace the ball joints in my truck. Now everything is greaseable. :-D
The Moog parts I've used have been pretty good, but I usually prefer Timken if they're available. I've had to work on machines in a few Timken factories, and they really do seem to give a damn about quality.
How about the fact that he has been driving it ignoring the "thunk Thunk" noises for 5,000-10,000 miles? If a ball joint is failing it thunks. They guy ignored it for months.
I'm wondering about this as well. Short of a truly random catastrophic failure, ball joints (and most suspension components in general) give plenty of warning when there are problems. I'm no Tesla fanboy by any means, but any marginally attentive driver should have noticed handling issues well in advance of the failure. Rusty ball joints would have been making all kinds of noise and grinding sensations long before then.
Same for my poor abused 2002 GMC Sierra pickup with 135K miles. Coincidentally, I replaced the ball joints last November at about 125K miles (all four control arms, actually, because why not if you're already going to be in there), and the front wheel hubs in February (which took all of 15 minutes per side). It's been a remarkably trouble-free vehicle, all things considered.
I'm also wondering how you drive a car long enough for a ball joint to break without noticing handling problems long before.
It's not really a scam - patents forbid even the mere use of a patented invention without a license. I agree that it's a crappy way to do business, but it's completely legal.
This. So many apps are asking for really inappropriate permissions, and I just don't have the time or motivation to deal with it.
Wouldn't be Slashdot without the obligatory and completely-unrelated-to-anything-in-the-thread post about APK!
Comcast has to supply an enormous back-end with many peering contracts, many interconnects, and much more hardware.
So does Level3, Cogent, and every other provider. I pay $29/month for a dedicated server with unlimited bandwidth on a 100 Mbit port, and in addition to bandwidth and the machine itself, my provider is paying rent for the cage in the DC, power, UPS, staffing, and all kinds of other expenses. Providers like 100TB.com offer much better deals than that and still manage to turn a profit. Cogent bandwidth by itself is often less than $1.00/MBit/month with a 1 Gbit commit, although it's more like $3-4 for better providers. Owning the equipment, I'm sure Comcast's cost is much less.
As was duly explained to the more recent employees, Lockdown was a state of war that dated to Facebook’s earliest days, when no one could leave the building while the company confronted some threat, either competitive or technical.
"I can't leave the building? Well, here's my badge. Fuck you."
Well, I never had any problems with AmigaBASIC, and released a shareware editor for the Yamaha DX-7 synth written in it. It didn't give you easy access to the system libraries, but it wasn't intended to be a professional development environment. AmigaBASIC wasn't "dumped" - it was still being distributed in 1.3, and ARexx was a higher-level scripting/macro language, not a general purpose programming language.
The point remains that your claim that the Amiga didn't have a working programming language available is provably false. Being unable to use those languages doesn't mean they didn't exist.
an Amiga that had no working programing language available
:-D
Sure there were - the Amiga originally came with Metacomco's ABasic - it wasn't great, but it was functional, and Metacomco also had a decent macro assembler available when the Amiga came out. When AmigaDOS 1.2 came out, they switched to Microsoft's AmigaBASIC. The Lattice and Manx C compilers came a little bit later.
Still have my A1000, the Manx compiler, the Metacomco assembler, and the RKMs.
Slacker! In my day we did "CALL -151" and entered the hex codes directly! ;-)
I was forced to take a semester of Latin in high school. I would never ever have taken that willingly, but having gone through it I can see that in another life I might have pursued linguistics. Who knew?
I only took Latin in my senior year of high school, but I really enjoyed it. My teacher was actress Eileen Brennan's sister (looked just like her), and had gone through a bad divorce and would teach us all kinds of hilariously abusive phrases. Sadly, I remember almost none of it but I wish I had taken more foreign language classes earlier.