The rise of Microsoft was everyone wanting a machine like the one at their office, because the buying businesses made it cheap.
Now it's ARM & *nix making mobiles cheap while laptop & desktop prices rise due to reduced output. The secret is cross-vendor "collaboration" (GPL-enforced, buying-selling hardware designs, fab-sharing), which MS & Intel don't do. Economies of scale do interesting things to the non-collaborative world. The tipping-point will be ubiquity: do you want to develop on something you can take anywhere & have specific knowledge be legally valuable to many, or do you want to develop on something uncommon that you can't transfer to another job if this employer goes?
Re:Collateralized vs Non-Collateralized Loans
on
Let Them Eat Teslas
·
· Score: 1
Caching the way a button looks, the way your titlebar looks, possibly down to each letter on the screen.,All these are stored Client-side by the Server's request, so instead of sending a 24bpp bitmap of the word "cat" (a few kb), it references a previous: "c.jpg, a.jpg, t.jpg" (which is only a few bytes). It also caches whole windows so a window move isn't expensive.
"developers open admit they were not database guys when they started" And how were they supposed to be, by working at Oracle first? Oracle's DB wasn't made by guys experienced with Oracle when they started.
"do in the application".... "data management" What is it you're saying it lacks?
"database server does work" Stored procedures & triggers are a nightmare for upgrading software, because you must take a DB offline or carefully delete triggers on upgrade of the app using it. It is this way because this way works better.
Foundations for Wayland, KVM, KMS, systemd, Dalvik. Many of these things should just be a compile away with the right few pieces in place. Don't get left behind & don't let Linux's advancements be an island
- Session-Oriented == hacks for log-in screen - Tied to VTs - Crashes take down all clients - Takes 3 programs to draw a window: the application (hosting a lib), the window manager, the compositor - Complex drivers tied to 1 version of X11 - Driver switching is impossible: it would take down all clients - Hardware manipulation living outside the kernel (requiring root when we shouldn't) - More lines of code than the Linux kernel - Copy/Paste can't survive source program shutdowns (very common in Mobile) - Remoting (& other pieces like Font) can't be fixed, but only wrapped or ignored, so we don't even know what doesn't work with X - "Dead" code costs memory & load time - Its model poorly fits hardware-accelerated toolkits.
X is hard, so most programs actually rely on a toolkit, like: - GTK: Ported to Wayland - Qt: Port in progress - SDL: Port in progress - EFL: Ported - Wine: Port being considered
So you're right that nobody will write Wayland programs, but nobody writes X programs either.
Clustered filesystems were always very brittle in the past: - a few controllers ran everything (single point of failure) - limited access to them (special APIs you're expecting) - difficult administration adding nodes and properly replicating
Advances have fixed these in Gluster, but it's new. There will be no "targeted software" since it's a filesystem. And as open-source, a 60-person company can easily produce something consumable by a huge company since they can share support effort.
The internet isn't necessary to teach typing & office skills on Libre-Office. Wikipedia has books you can copy to disk & bring there for CS & more. If you're without internet access, that may turn your lab into a "library" lab. I'd bring some hack-friendly environment or lib with references & examples, like: - PyGame - GameJS - Electronics hacking (Raspberry PI).
Breaking-down the obvious: - Laymen could get Reader's benefit - Geeks saw a product that only told Google that some RSS source interested them. - Those geeks like Google's open-source policy & assumed to unprofitable would become open-sourced. - Reader wasn't open-source, tarnishing this image. - A simple open-source promise could save them a lot of hassle.
Unless perhaps Google wants to give free cloud services a black-eye? It certainly made me consider installing my own jsPerf instance.
Each needs to support a browser that does graphics, audio, video, etc. So I'd push for similarity: Kernels & platform components. That reduces code duplication (thereby reducing bugs & freeing dev time).
Then Chrome OS gets reliability benefits from Android's user base (public bug testing), and Android gets great native (non-Dalvik) components for better performance.
This means we have another 10x to 100x clearer details about the universe's origins, which should be enough to invalidate some theories & spend time on the more promising ones.
Go further: banks could collect a "incoming wealth" tax & send it in for you. They already interact with the government regularly. It would be even fewer entities involved.
DRM requires a trusted path to the final renderer. That can't be implemented in a standard. If I wanted to screen-scrape Netflix on Android, I'd need to replace the Kernel, which Netflix detects is unsigned & refuses to run. Standardizing wouldn't block screen-scrapes. Therefore there is no point in a standard except legitimacy.
The best battery savings is in a race to Idle. A faster phone means faster results so you'll turn-off your screen earlier, which is often the biggest power draw. Continuous uses like video can involve "buffer..sleep" cycles which involve more sleep on a faster processor.
You get this savings even if the power cost scaled equally to the CPU difference (likely better than that).
Teach him as you write documentation: Literally type notes with him watching. He will forget & probably quit before you get asked back, so you need proof that you did impart "secrets".
But don't be surprised at some negativity to you when it all goes South. Well-known places (for new devs under new managers) to find your typed-up training info will be key to positive referrals.
RSS, Federated XMPP, and Google Wave are all federated protocols that Google's not working with anymore. We need better federated protocols to catch-on (by being well supported) now that email is looking ancient.
Everyone has an email address because anyone can run an email server, not because a handful of mega-tech companies elected to work together. Email has no central point of censorship or ad-scanning. The same isn't true for any discussion page, twitter, social media, etc.
HTTP is mostly decentralized (except DNS & SSL) and is the basis of today's Internet. Decentralized protocols make the world grow. Axing them kills progress.
Agreed. We need knowledge to be available long-term. The only reason this story feels irrelevant is because we've given-up on going to Libraries to get information. Unencrypted Epub as a standard may be a good start, but there's nothing pushing for this. The libraries were the strongest opposers of copyright extension & DRM, strangely the rise of the Internet weakened their say & let the publishing industries push copyright absurdly.
They can only announce blame if they're in business. Paying for years of development & receiving few sales will fix that. And it doesn't even need to go that far, just a few bad burns and they'll wise up. The Humble Bundle & App Stores (Android / iOS) are part of a changing landscape as life routes around their trouble.
Doing something at 100x less cost is a big deal. Sure it took political influence to be the NASA's first commercial sale. In the end he even saved taxpayers money, so what's not to like?
Driving coast-to-coast without using gas is a chicken-and-egg problem. I'm glad to see someone taking-on the stranglehold of world's largest cartel, with some success.
Slashdot Mirror
The rise of Microsoft was everyone wanting a machine like the one at their office, because the buying businesses made it cheap.
Now it's ARM & *nix making mobiles cheap while laptop & desktop prices rise due to reduced output.
The secret is cross-vendor "collaboration" (GPL-enforced, buying-selling hardware designs, fab-sharing), which MS & Intel don't do.
Economies of scale do interesting things to the non-collaborative world. The tipping-point will be ubiquity: do you want to develop on something you can take anywhere & have specific knowledge be legally valuable to many, or do you want to develop on something uncommon that you can't transfer to another job if this employer goes?
You're just mentioning the current situation.
Caching the way a button looks, the way your titlebar looks, possibly down to each letter on the screen.,All these are stored Client-side by the Server's request, so instead of sending a 24bpp bitmap of the word "cat" (a few kb), it references a previous: "c.jpg, a.jpg, t.jpg" (which is only a few bytes). It also caches whole windows so a window move isn't expensive.
" program cells to do everything from monitor pollutants ..."
I don't want them to pollute my monitors!
"developers open admit they were not database guys when they started"
And how were they supposed to be, by working at Oracle first? Oracle's DB wasn't made by guys experienced with Oracle when they started.
"do in the application" .... "data management"
What is it you're saying it lacks?
"database server does work"
Stored procedures & triggers are a nightmare for upgrading software, because you must take a DB offline or carefully delete triggers on upgrade of the app using it. It is this way because this way works better.
Foundations for Wayland, KVM, KMS, systemd, Dalvik. Many of these things should just be a compile away with the right few pieces in place. Don't get left behind & don't let Linux's advancements be an island
- Session-Oriented == hacks for log-in screen
- Tied to VTs
- Crashes take down all clients
- Takes 3 programs to draw a window: the application (hosting a lib), the window manager, the compositor
- Complex drivers tied to 1 version of X11
- Driver switching is impossible: it would take down all clients
- Hardware manipulation living outside the kernel (requiring root when we shouldn't)
- More lines of code than the Linux kernel
- Copy/Paste can't survive source program shutdowns (very common in Mobile)
- Remoting (& other pieces like Font) can't be fixed, but only wrapped or ignored, so we don't even know what doesn't work with X
- "Dead" code costs memory & load time
- Its model poorly fits hardware-accelerated toolkits.
X is hard, so most programs actually rely on a toolkit, like:
- GTK: Ported to Wayland
- Qt: Port in progress
- SDL: Port in progress
- EFL: Ported
- Wine: Port being considered
So you're right that nobody will write Wayland programs, but nobody writes X programs either.
Clustered filesystems were always very brittle in the past:
- a few controllers ran everything (single point of failure)
- limited access to them (special APIs you're expecting)
- difficult administration adding nodes and properly replicating
Advances have fixed these in Gluster, but it's new. There will be no "targeted software" since it's a filesystem. And as open-source, a 60-person company can easily produce something consumable by a huge company since they can share support effort.
Agreed! Why should oil be subsidied, but Sugar (also fuel) be limited.
It's not the final solution, but its legal consistency that helps immediately.
The internet isn't necessary to teach typing & office skills on Libre-Office. Wikipedia has books you can copy to disk & bring there for CS & more. If you're without internet access, that may turn your lab into a "library" lab.
I'd bring some hack-friendly environment or lib with references & examples, like:
- PyGame
- GameJS
- Electronics hacking (Raspberry PI).
Surprisingly-well. In-fact over the past 10 years it's almost doubled.
Breaking-down the obvious:
- Laymen could get Reader's benefit
- Geeks saw a product that only told Google that some RSS source interested them.
- Those geeks like Google's open-source policy & assumed to unprofitable would become open-sourced.
- Reader wasn't open-source, tarnishing this image.
- A simple open-source promise could save them a lot of hassle.
Unless perhaps Google wants to give free cloud services a black-eye?
It certainly made me consider installing my own jsPerf instance.
Each needs to support a browser that does graphics, audio, video, etc. So I'd push for similarity: Kernels & platform components. That reduces code duplication (thereby reducing bugs & freeing dev time).
Then Chrome OS gets reliability benefits from Android's user base (public bug testing), and Android gets great native (non-Dalvik) components for better performance.
This means we have another 10x to 100x clearer details about the universe's origins, which should be enough to invalidate some theories & spend time on the more promising ones.
Go further: banks could collect a "incoming wealth" tax & send it in for you.
They already interact with the government regularly. It would be even fewer entities involved.
DRM requires a trusted path to the final renderer. That can't be implemented in a standard.
If I wanted to screen-scrape Netflix on Android, I'd need to replace the Kernel, which Netflix detects is unsigned & refuses to run.
Standardizing wouldn't block screen-scrapes. Therefore there is no point in a standard except legitimacy.
The best battery savings is in a race to Idle. A faster phone means faster results so you'll turn-off your screen earlier, which is often the biggest power draw. Continuous uses like video can involve "buffer..sleep" cycles which involve more sleep on a faster processor.
You get this savings even if the power cost scaled equally to the CPU difference (likely better than that).
Teach him as you write documentation: Literally type notes with him watching. He will forget & probably quit before you get asked back, so you need proof that you did impart "secrets".
But don't be surprised at some negativity to you when it all goes South. Well-known places (for new devs under new managers) to find your typed-up training info will be key to positive referrals.
All the while viewership for television newscasts has dropped dramatically in the past 2 decades.
RSS, Federated XMPP, and Google Wave are all federated protocols that Google's not working with anymore. We need better federated protocols to catch-on (by being well supported) now that email is looking ancient.
Everyone has an email address because anyone can run an email server, not because a handful of mega-tech companies elected to work together. Email has no central point of censorship or ad-scanning. The same isn't true for any discussion page, twitter, social media, etc.
HTTP is mostly decentralized (except DNS & SSL) and is the basis of today's Internet. Decentralized protocols make the world grow. Axing them kills progress.
Agreed. We need knowledge to be available long-term. The only reason this story feels irrelevant is because we've given-up on going to Libraries to get information. Unencrypted Epub as a standard may be a good start, but there's nothing pushing for this. The libraries were the strongest opposers of copyright extension & DRM, strangely the rise of the Internet weakened their say & let the publishing industries push copyright absurdly.
They can only announce blame if they're in business. Paying for years of development & receiving few sales will fix that. And it doesn't even need to go that far, just a few bad burns and they'll wise up. The Humble Bundle & App Stores (Android / iOS) are part of a changing landscape as life routes around their trouble.
Android software? Java?
Doing something at 100x less cost is a big deal. Sure it took political influence to be the NASA's first commercial sale. In the end he even saved taxpayers money, so what's not to like?
Driving coast-to-coast without using gas is a chicken-and-egg problem. I'm glad to see someone taking-on the stranglehold of world's largest cartel, with some success.