552 karma · joined August 18, 2015
Weisman had created a detailed story arc that had a couple more centuries to go. He has continued to answer never ending fan questions and reveal details of the story arc for the following 20 years at "Ask Greg" at Station 8 Gargoyles
Mork & Mindy (RIP Robin Williams) became the #3 show in America in its first season. Come season 2, the network (ABC) fired the entire supporting cast and changed its timeslot to go up against Archie Bunker. Even back then, most people had enough sense to know to not mess with something that worked, but you wouldn't know it from the network executives. The show was never able to recover.
Such an article would also have to look at the costs to make each show, which it does not. (I expect Firefly to be more expensive than Veronica Mars due to things like special effects, and Joey expensive due to Matt LeBlanc.)
And it would have to consider monetization models for each, where shows with ads have to concern themselves more about advertiser friendly demographics vs. premium pay shows have to find a demographic that is willing to pay directly for TV.
In this case, it really feels like they "have this great idea to clean up the comments" problem that "doesn't require Google to do any work". It feels like they were willing to buy into the hype around Gamification of everything to solve their all problems to justify an internal aversion to solving problems the hard way, which would require Google to pay for actual human labor.
It was "win-win" in their echo chamber because it doesn't cost them much in terms of effort or money, while content creators should be happy Google is trying to improve the situation.
Another good example is the case of Eli the Computer Guy. He is an interesting content creator because he has actual marketable skills outside content creation and has built his own businesses before. He was a focal point last year during another YouTube controversy which later became known as #WTFU. After getting screwed by "The Algorithm", he announced he was leaving YouTube because the environment was not conducive to building a serious business around. One of the stories he told was he used to have a Google Content Partner, an actual human he could talk to if he had problems. Then shortly after, that person announced she got a promotion and was leaving with no replacement. "But don't worry, we have a great solution for you. You can use our forums if you have questions."
Eli has gone on about how dense they were that they didn't understand that this was a terrible thing and forums were no replacement for an actual person.
It was one of many examples he cited about how out of touch Google is with their own community. Eventually, after this controversy, they managed to keep Eli on YouTube for now, doing the "bare minimum" to keep him, which includes giving him a person to talk to. But there are much bigger YouTube creators who still don't have anybody they can talk to.
https://www.youtube.com/watch?v=wua96SI6SBE&list=PLPAVYgFfed...
The YouTube Heroes program antagonized the content creator community by:
1. By trying to get free labor to clean up the comments system instead of doing it themselves.
2. Creating new concerns about who is going to watch the watchers.
3. Showing new management features for Heroes that content creators themselves have been asking for and still can't get.
This secret video edit is another slap in the face because:
1. It potentially undermines public responses they've already posted based on the original video and new people (and trolls) may call them out their complaints that no longer match up with what is said.
2. It shows yet another feature YouTube content creators have been asking for, but can't use themselves.
I don't think Google is intentionally trying to tick off their own community, but it is amazing how dense they are. And for content creators, this is just another instance of Google not listening to them.
But Intel likes Apple Macs as a show pony. Intel has for years been desperately trying to convince hardware manufacturers to make both more consumer appealing PCs and new consumer devices around their chips. PC makers kept making the same old big beige towers, with the only differentiating factors being price (race to the bottom) and speed.
Apple doesn't like to compete in that space and likes to do other things and pushes on different features of chips that allow them to make smaller machines, quiet machines, fully integrated machines, battery friendly machines, and focus on industrial design.
Intel knows this and likes to use Apple to push other manufacturers to think in similar ways. The results have been pretty good as there are now PC competitors that make things like the All-in-one-flatscreen iMac, and the Macbook Air. If you remember way back before the iPhone, the original Apple TV was Intel based and showed Intel chips in mainstream consumer non-PC use cases. (This is different than concept demos because this was a real shipping product that actually managed to make enough money to sustain itself.) Also, Apple's obsession with reduction, like eliminating ports has been good for Intel because Apple helps encourage adoption of new standards they want to put out. For example, Apple embraced Thunderbolt at the beginning and was willing to drop legacy ports while most manufactures would normally hedge by keeping legacy ports. Apple pushing hard on this helps makes the 3rd party adoption faster which emboldens manufacturers to migrate faster themselves.
Remember they were called Powerbooks back then? I miss that name.
The reason Windows on Mac is useful to people is because people have may programs that do not have acceptable equivalents on Mac OS. These apps are usually legacy programs that probably fill special niches, and the cost of "modernizing" is usually not justified. This effort would be required to port these apps to Windows ARM, which last time around also required porting to UWP which Microsoft is still pushing, but not easy to actually do for a lot of code bases.
A new Microsoft irony kicks in here is that if they are successful in convincing the huge Windows ecosystem to migrate to UWP away from Win32, et. al, they may actually kill their lock-in advantage. A serious rewrite at this stage may also invite Mac, Linux, iOS, Android ports. In this case, Apple no longer needs to care about Intel Windows and this bullet point becomes less compelling and maybe they could reconsider.
People are concerned that they have some mission-critical, unreplaceable app that only runs on Windows, that has no acceptable Mac analog (doesn't exist, doesn't have feature parity, data formats are incompatible).
Windows on ARM doesn't solve anything because almost no Windows apps that people care about were ever ported to Windows RT. (It was probably more likely there was a Mac port.)
In the PowerPC days, Apple had trouble convincing people to switch to Mac because Windows being so dominant, everybody was afraid they might need Windows for something and that would make a PowerPC Mac an expensive mistake. The Intel switch alleviated many fears because in the worst case and Mac OS didn't work out, they could just install Windows. Bootcamp and virtualization provided additional options.
Apple has always seen Mac and iOS as different markets. Mac is still a small market compared to Windows. They are still trying to grow which means still trying to convince Windows users to switch and the safety net of Intel is still useful. (Windows RT isn't a realistic option.) I personally haven't seen iPhone users wishing for a big laptop or desktop that runs their same apps.
And for a lot of the older Mac developers, iOS was kind of like another migration. And iOS has gone from armv6 to armv7 to arm64, plus the x86 and x86-64 simulator targets. Not to mention that there is now an LLVM Bitcode requirement for Apple TV and watchOS.
Apple and its developer community has a lot of experience with architecture migration. Each transition built on the experience of the previous and got smoother each time. Apple has been very good insulating their frameworks and tools from the architecture, and the Apple developer community has gotten very good at following Apple's guidelines to minimize disruption since there have been so many of these transitions.
http://www.vanityfair.com/news/business/2012/08/microsoft-lo...
Some excerpts:
By 2002 the by-product of bureaucracy—brutal corporate politics—had reared its head at Microsoft. And, current and former executives said, each year the intensity and destructiveness of the game playing grew worse as employees struggled to beat out their co-workers for promotions, bonuses, or just survival.
Then, in June 2004, Steve Jobs announced that Apple was releasing its new operating system, called “Tiger.” And inside Microsoft, jaws dropped. Tiger did much of what was planned for Longhorn—except that it worked.
E-mails flew around Microsoft, expressing dismay about the quality of Tiger. To executives’ disbelief, it contained functional equivalents of Avalon and WinFS.
“It was fucking amazing,” wrote Lenn Pryor, part of the Longhorn team. “It is like I just got a free pass to Longhorn land today.”
Vic Gundotra, another member of the group, tried out Tiger. “Their Avalon competitor (core video, core image) was hot,” he wrote. “I have the cool widgets (dashboard) running on my MAC right now with all the effects [Jobs] showed on stage. I’ve had no crashes in 5 hours.”
Longhorn was doomed. A few months later, Allchin brought together the Longhorn team and made the announcement: Microsoft couldn’t complete Windows Vista in time to hit the latest planned release date. In fact, the company couldn’t foresee any launch date. So a decision had been made at the most senior reaches of Microsoft: after three years of work, throw everything out and start over. It was decided, at least for now, to drop or modify many of the original objectives; no more using C#, abandon WinFS, and revise Avalon.
Apple was already in the market with those features; Microsoft was basically giving up in its effort to figure out how to make them work.The author also argued that Apple's lock-in like iMessage isn't really working. Thus, this is how Android gets to 100%.
This disregards the fact that many iPhone customers are still first time buyers with no lock in hanging over their head. And also Apple has an extremely high customer satisfaction rate keeping customers coming back. Customers buy iPhones because they like the experience and ecosystem, not solely due to some service lock-in.
- She made three passes to fix the existing code base.
- After that didn't work, with the CTO's involvement, this Go solution was devised.
- It took only 2 weeks to ramp up with Go and build a replacement that solved the problem.
- The number of instances needed dropped from 4 to 2
This sounds like a resounding success.
So congratulations Alexandra and Digg. And thank you for sharing. The article was well written and I learned some things about how the Node.js event system works under the hood.
I've been hearing that myth a lot recently too. I checked the CDC to see the real numbers. Cancer (disturbingly all ages groups), and (traffic) accidents, and heart disease make up the lion's share. Even suicide is larger than murders.
They wanted something easy to deploy (single executable), easily portable, very small CPU footprint, and very small memory footprint.
Lua is well regarded for all these things, and the company succeeded in meeting all these objectives.
Congratulations Distelli. Nice job. And thanks for sharing.
The ABI between g++ transitions is also platform and architecture dependent. Mac was PowerPC back then. Sun used Sparc. Not everything is always x86, even on Linux.
I had similar problems on Linux and Solaris because of that transition. My own fault (actually my employer's) for assuming binary compatibility when it was never promised.
As a result, some issues arise, such as code that is stuck on GPLv2 (e.g. removed the upgrade clause like the Linux kernel) may be incompatible with LGPLv3.
This blog tries to explain some of the issues. http://nmav.gnutls.org/2013/03/the-perils-of-lgplv3.html
C++ generally incurs a price on link times too. For example C++'s stronger type system creates more burden on the name mangling, like there is actually a difference between an int and long, even if they are the same size on the system. Then if you have code that doesn't make this distinction, overloaded functions need to be generated which creates more generate code bloat. Then if you throw templates into the mix, C++ generates a ton of symbols for every permutation. This is why C++ object files are usually much larger than C object files and why the linking process is so much slower.
Instead, this is actually one of the best articles I've read about WebAssembly. The author approaches it from a C/C++ background and investigates what it means to write applications from that mindset, revealing the huge limitations of asm.js. Then the author turns to WebAssembly and gives a sobering look of how immature that project still is.
Function pointers are one scary area. I don't know if C++11/C++14 decided to fix this yet. Most people relied on undefined behavior to make this work.
Public records that aren't public aren't public records.