if I wrote a script to go through MySpace looking for other "stuff?" Isn't this a breach of privacy
Kind of depends. I mean, you intend to make information public when you publicly post it on MySpace, right? So why would you be upset when people start looking for that information? Search engines used to be able to find personal webpages when those were all the craze.
The truth is, if you are concerned about privacy, don't make your personal matters public. Share only what you're willing to tell people, and hide things that should only be shared with a select few behind passwords. Then if someone breaks your security (even if it's fairly simple security), you at least have a case for your privacy being violated.
Am I the only one who can't get worked up about this exploit? I mean, I should be thinking, "this is happening because of X, we should do Y to fix it!" And yet, I just can't develop an opinion either way. It's not that I'm wrestling with myself, it's just that I don't care.
Analyzing this, I think the reason is because the NVidia and ATI drivers are a PITA everywhere. By installing the drivers, you agree to destablize your system in exchange for the most incredible 3D (and 2D to a certain degree) performance. When Something Bad Happens(TM), you just sort of take it as coming with the territory.
It's sort of like hooking Nitro up to your car. Sure, your engine is more powerful than ever. But are you really all that surprised when you bust a valve, crack a ring, or do some other form of damage to your hotrod?
It would be nice if OSS drivers could be created. But it's probably not going to happen. NVidia won't open their drivers (ATI, doubly so) and the OSS community doesn't have enough info to recreate them. Thus I think the best bet is the Open Graphics Project. If they produce a viable 3D card alternative, you'll finally be able to chose between a stable (but slower) 3D card, or a high-performance, hotrod 3D Card. Take your pick to meet your needs.
Oh, and keep a firewall in front of your machine and the internet. Pipe all your X communications over SSH. Just good safety sense.;)
Console gaming historically has required proper QA, but I wonder if this will change as patches can be provided to console players just as they have been to PC players.
To a certain degree, I think you're already seeing the PSP gamers revolt. Quite a few of them have moved on to the Nintendo DS, which does NOT send out large system patches to fix "system issues". Especially when most of those "issues" are attempts to plug holes homebrewers are using.
Overwriting the MBR is reckless, it isn't their data
In case you didn't notice, you are installing an operating system. Generally speaking, machines have always shipped with one OS to control the entire system. It is certainly *not* unreasonable for Microsoft to overwrite the MBR. Especially when they expect that their OS will be the only one. You'd have a hard time convincing a judge otherwise.
The fact that Microsoft hasn't improved this part of the install as more hobby OSes have showed up just goes to show how little they care about letting you use your hardware as you want to use it. But they are under no obligations, especially when the installer warns you to make backups before you run it.
Developers don't know what to do with staff once a project winds down because the nature of the industry is such that nobody can guarantee constant work. When working in a low-cost market such as 16-bit development, this problem existed as it does today, but the negative weight of it was relatively insignificant. Yet as costs and contract issues and the seriousness of the industry has grown, the problems of having fifty or a hundred people doing nothing for an extended period of time have multiplied that negative weight, to the point that it kills companies.
Sounds like many game companies need to learn a newfangled idea (not really) known as "pipelining". You have various projects happening concurrently, with each project bubbling to the top as the necessary parts of the previous one are completed.
This would require good management, more normal working hours, and game development on a more normal schedule in order to happen. These things have been an antithesis to game companies, who have always struggled under tight timetables to get the game out while it's still technologically impressive. One is forced to wonder, though, is the technological death march really worth it? If your company's very existance is dependent on producing blockbuster after blockbuster, then you may be in a pretty bad position. No one can maintain a permanent streak, which is why you're probably only employed as far as the next game.
As much as I dislike EA, they do understand. (To a certain degree.) They have tons of projects in parallel, assuring that resources can be used and transferred as necessary. There's no "negative weight" holding the company down, save for post-launch vacations. If they would smooth out the development process, they could let everyone have lives so that they wouldn't need the post-launch vacations. Then their negative weight would reach pretty close to zero.
Games just aren't getting that much more impressive as time goes on. We're reaching areas of dimishing returns to where we can probably slow the pace in exchange for focusing on making good games that are fun, and have been properly QAed. There's no need for these last-minute additions or patches. Especially as the market revolts, and moves more and more toward console gaming. (Where proper QA is a requirement.)
Gamers want good games. Technology is only a canvas on which games are painted. It should not be the be-all-to-end-all of the game. If companies can reorganize around making high-quality games on more reasonable schedules, then I don't doubt that costs would lower and the products would improve.
Frankly people seemed concerned that they would look "stupid"...
...all while bouncing around on a Dance Dance Revolution machine.
The double-standard of this "I'll look stupid" and "it's too much exercise" argument kills me. DDR was one of the most popular games in history (greatly improving PS2 & Dancepad sales), yet people worry about holding a remote control? The way I figure it, most couch warriors are used to holding remotes. There's not much on TV, so it's *flip* *flip* *flip*. Plenty of exercise for warming up to the Wii.;)
The one part of the article that really stuck out at me, though, was the comment that "large motions is how you have fun". I don't know how many people here have played Laser Tag-type games, but the sweeps and motions you make with your weapon are quite different when you're relaxed and when you're pumped. When you're relaxed, your reaction time is extremely slow. You tend to use extremely fine movements in attempts to aim, and may even tilt your wrist quite a bit. Yet when you're pumped, you work the floor, dodging, sweeping, and rolling. Your arm is primarily used for targetting, and you gain quite a bit of precision because of it.
It's just a lot more fun to get up and exercise. It releases a lot of good hormones that make you enjoy yourself. Besides, there's nothing quite like professionally strapping on your gear, just to have the guy next to you asking, "Have you ever played this before?" Oh yeah, bring it on.:D
[Jobs is] saying that it's too complicated to be useful right now
Give the man a prize. This was exactly Jobs' point. He didn't say anything to suggest that he's opposed to the idea of wireless transfers, just that the Zune sucks at it. If the iPod were to add this feature, it would probably require you to cross the room, stand next to the girl (again, giving you that chance to talk to her), and very simply and painlessly initiate the file transfer. Knowing Apple, you'd probably be able to broadcast your current playlist to nearby iPods, allows you to pod-jack without even pod-jacking. Which would be in support of existing market needs (something which Apple excels at) rather than trying to force a feature onto the market that no one is asking for.
I do hope you were calling it "Zuma" repeatedly as a joke, considering even the text you quoted referred to it properly as the "Zune".
Ha! That's pretty funny. If you check the comments, you'll note that I've got other people doing it too! I wonder if the "misheard lyrics" sites will take this one?:P
Seriously, I need more coffee. I somehow always read "Zuma" when I see "Zune", and I just don't care enough about Microsoft's sinfully-ugly music player (at least at this hour of the morning) to get it right. I suppose that doesn't bode well for their marketing plans. Unless, of course, they simply try to crush the competition using their Windows monopoly. Microsoft would never do something like that, though....
I would be shocked if Jobs said anything otherwise. What's our next headline for Slashdot? Is it going to be "Steve Ballmer's Kids Love Zune"? What about "Jobs Says New Mac Models Are Good"? You gotta keep up those hard hitting headlines.
How is this news? Simple: By reading between the lines.
Every company delivers the same BS of, "We think our competitor provides no real challenge in the market." But if you actually listen to what they're saying, you can hear what they really think about it. Sort of like how Ballmer's denials of Google's importance always come across as, "I want to throw a f#@$ing CHAIR at those Google DEVELOPERS, DEVELOPERS, DEVELOPERS!"
It always amazes me how smoothly Jobs manages to deliver presentations, even when he's put on the spot. And without any of the dodging and doublespeak you expect from most company execs.
I know a lot of Slashdotters hate iTunes for "DRM", "not HD(TV) quality", "too expensive", or whatever other B.S. excuse they can come up with, but...
Q: No, but you've asked them not to raise their prices, when some of them wanted to. A: Our core initial strategy on the store was that if you want to stop piracy, the way to stop it is by competing with it, by offering a better product at a fair price. In essence, we would make a deal with people. If they would pay a fair price, we would give them a better product and they would stop being pirates
...THIS is why I support iTunes. They know they have to be competitive in the market, so they are. They keep prices acceptable, even in face of stupid, greedy record companies. Jobs makes no bones about it, and he tells both the labels and the consumers the same thing. There are no "backroom deals" going on here, just a company trying to deliver the best product possible at a price the market can afford.
You won't find that sort of business done at Microsoft. Their strategy is:
1. Announce a competing product with limitless fanfare. Doesn't matter if it sucks. 2. Slowly improve it until the market finds it semi-acceptable. 3. Leverage the Windows monopoly to CRUSH the competition.
Didn't you hear? You can only use iPods with a Mac. With Zuma, you can be compatible with the millions of Microsoft Vista machines, out of the box! Plus, you know you're getting Microsoft Quality(TM) and Support(TM) when you purchase a Zuma. Those other digital music companies could fold tomorrow, leaving you with no music and no refund. Only Microsoft products can provide you with a guaranteed safety net! </standard-Microsoft-bull>
I've seen the demonstrations on the Internet about how you can find another person using a Zune and give them a song they can play three times. It takes forever. By the time you've gone through all that, the girl's got up and left! You're much better off to take one of your earbuds out and put it in her ear. Then you're connected with about two feet of headphone cable.
You know, he's got a point. It might seem very impressive in a geeky way to Zuma a file across the room to the pretty girl (if you don't mind that I just used "Zuma" as a verb), but she is definitely not going to be impressed unless she's also a geek. You've also got the matter of the song being played in a vacuum, where your own thoughts and feelings on the tune are missing. Thus it holds no meaning. Besides, pod-jacking gives you a much better chance of being able to talk to that pretty girl.;-)
I did a quicky review of Google's Spreadsheet when they released it six months ago. Since then, it would appear that Google has fixed some of my complaints. In particular:
1. Cell borders have been added.
Umm... that's all I've got.:(
Everything else still appears to be an issue, including the calculation errors I spotted. And while Cell Borders have been added, there is no way to apply different styles. I'm pleased to see that Google is adding a new API for their "Office Suite", but they really need to fix some of these issues before they can be taken seriously.
Also, the continuing lack of charting is really sticking out. Data visualization is an important feature in a spreadsheet, whether you're preparing a market analysis or just balancing your household budget. The fact that plenty of web technologies exist to accomplish charting (SVG, round trip images, Flash, Java, etc.) only makes it stick out that much more. Now the API might allow external coders to help in this area, but so far I'm still not impressed.
No one has seen or heard of Enlightenment in so long, that he probably thought the icon was for "enlightening" topics. Either that, or he missed the button again.
PLEASE Scuttlemonkey, don't fire him again! He's just trying to keep up with Slashdot tradition.;)
Re:IT, No T, any job is the same
on
IT and Divorce?
·
· Score: 3, Insightful
any job is the same
There is some truth to this. Nearly any coporate job demands long hours and tough working conditions, all so you can make a few extra bucks. Having both spouses working only exasperates the difficulties in spending time together. In a good relationship, both of you should naturally have a clear idea of what each other is up to. There's no need to give each other the first degree, or hang off each other. Just spending time together, talking a lot, and doing the things that couples do can go a long way toward saving the marriage. Unfortunately, this takes a LOT of effort, isn't very easy, and requires the commitment from both sides.
Having kids only puts more demands on your time. They need just as much of your time as your spouse does. That time, however, does NOT replace the alone time you need with your spouse! Just because you both spend time with your kid doesn't mean that you don't still need intimate time (physical, emotional, and otherwise) with each other. Just something to keep in mind.
BTW, check out my current sig for a geeky way to give your kids "daddy time".;)
Everybody thinks 1998 is coming back and the VC crowd is so hot again.
I'm not aware of anyone who thinks that. VCs have been around for a very long time now, investing in multitudes of startups. Where do you think Silicon Valley's big tech companies like Apple, SGI, Sun, and others came from? They all had VC money to start their businesses with. The only difference is that we now live in a connected world where things like Venture Capital are more readily spoken about in open forums.
Can we please get back to the tech?
I hate to break it to you, but tech usually needs funding for development. Venture Capital is one way of getting that funding. It's especially important if your plans require that you build a large corporation to properly develop and exploit the technology.
There's a better than average chance that Venture Capital is partly to thank for your current job in technology. Especially if you're working on the more cutting edge developments rather than menial business-support tasks.
I'd just like to thank Mr. Gorman and Salil Deshpande for answering all our questions, and providing such useful and insightful information. These answers are some of the best I've ever seen on an Ask Slashdot. They are informative, straight to the point, and well researched. You may very well have enabled a new generation of entrepenuers.
I'm not disagreeing, just correcting that part of your recollection. If you remember, the missing day not only caused the massive economic damage you mentioned, but also nearly resulted in Scrooge loosing his third-world factory and being shot. The nephews had to use their Junior Woodchuck Guide on Solar Eclipses to prove that the day was actually Thursday. Then Launchpad had to clear the clouds so they could see the Eclipse before Scrooge was shot.
After they proved the calendar date, they almost got a second allowance out of it, too!;D
That morning, by the time the nephews got to the mall to spend their "early" allowance, the global economy had collapsed and they couldn't buy anything.
Close, but not quite. The nephews really wanted a scooter, and there was a sale until Friday. Which meant that they needed to get their allowance on Thursday if they wanted to be able to afford it. Their shenanigans backfired when the store clerk was also convinced that it was Friday, and thus the sale was over.
Yeah, yours. It doesn't matter where DLL's go. If program A at version X depends on program B at version Y, that dependency can be ANYTHING.
A dependency installed to the core system is a lot different than a program carrying a dependency externally. i.e. If I have two programs that rely on foo.dll and we presume that foo.dll is not a system file, then each program has its copy of foo.dll and life is good. Each program can be tested independently and can still confidently work together.
Now if both programs try to install the non-system DLL foo.dll into the core system, then they will produce a collision. Which could have a variety of outcomes:
1. The two versions are the same, no harm done. 2. The two versions are different but compatible, no harm done. 3. The two versions are wildly incompatible, so only one program will run. 4. The two versions are mildly incompatible, creating difficult to trace problems for one of the programs.
The Linux solution to this problem is to make one of the two foo.dlls into a system library, and both programs should play nice within the package management repository. Which might happen, or they might require incompatible versions which the packaging system won't allow to be installed.
What's needed is a distro configuration whereby the library is standardized as either being there with a specific version or not. If the developer knows the library will ship on the system and is of a compatible version, then he doesn't need to worry. He distributes his package and life is good. If he knows that the library does not ship on the system by default, then he should ship his own copy for use by his program only. Period, end of story. Any other programs using that library will have their own copy. If the library is popular enough, then the distro designers would make an informed decision about including the library in the next major platform upgrade.
1) By your logic, for every piece of software I could install on a Windows machine (Q), there are 2^(Q-1) configurations to validate if I'm testing my specific product.
LOGIC ERROR
Windows programs rarely install DLLs into the core system these days. Which means there's usually only a handful of configurations to test (mostly impacted by service packs and different Windows versions). This is the case because Microsoft cracked down on system-installed DLLs after consumers were having problems with DLL Hell. Today, DLL Hell is mostly a memory. (No comment on the stupidity of one ActiveX control per system.)
The codebase is anything but monolithic.
It's not monolithically coded, it's monolithically designed. The monolith is the design of the packaging system which forces the exact programs and configurations available.
Debian isn't taking responsibility for the Mozilla codebase anymore than it takes responsibility for the linux kernel or glibc.
Then what, exactly, are they doing by trying to deploy their own patches? Oh yes, taking responsibility.
It's really easy to demonstrate that this is a bad assumption, by carrying it to the point of absurdity: OK, let's have self-contained programs include their own kernels. And their own filesystems. We can make little self-executing islands of them and run them with a virtualization environment.
By carrying it out to absurdity, you negate the purpose of the change in the first place. The idea is to have a stable core that can be targeted by all software. That core can be tested individually by each application. There will effectively be only one configuration that needs to be tested. Thus the problem of testing and deploying software can be cleanly pushed out to the software authors rather than the distributions.
Shared libraries go out the window and you use a lot more memory and even a lot more disk. Things start up slowly. Libraries that have compatibility tweaks for a specific platform aren't the ones used, you use your own ones and those break. And so on.
Yet the common Linux design at the moment is to do the exact opposite. i.e. Worry so much about shared libraries that you force the user to manage obscure, difficult to find libraries that should probably be included with the program in the first place. There's nothing more frustrating than trying to track down a tiny little package on RPMFind because the distro doesn't support it in the repository, you can't find the original website for the life of you (probably buried somewhere on a homepage), the RPMs/DEBs/whatever you've downloaded are all incompatible with your OS configuration, but it's actually REQUIRED by this major third party program that should really be in the repository in the first place. On top of everything, some idjut is telling you to change distros just so you can get compatible packages for this one program, but then you won't be able to run the 9,999 other programs you need. *sigh*
But you can get a lot of the advantages that you claim for rock-solid, manufacturer determined stable libraries by simply sticking with Debian's big repository, where everything is built together. It's only when you try to bring in something from a second repository that you have to depend on standards.
The Debian repository is a long ways from the be-all to end-all of necessary software. Perhaps the most difficult segment for any repository is games. New OSS Linux games are appearing fairly regularly. The proliferation of this segment makes it difficult to keep the repository up to date, and the base system moves so quickly that a binary today is likely to not work within a few months. And since the supplemental packages are NEVER distributed with the software in the Linux world (funny how that's almost never a problem on Windows or Mac?), you have to go back to the "track down the compatible package" nightmare.
I suppose you could determine a "standard" set of libraries and not have dependencies for those, because you can assume they are already there. But Debian already does that.
If you stick to Debian Stable, then that's generally true. Sort of, kinda, not really. In practice, -stable ends up lagging significantly behind the market, making it difficult to install recent software, while -unstable is exactly that: an unstable platform.
What you *want* is a stable core, and the ability to have either stable or unstable programs. Which means that program X over here might be perfectly happy with this year old GLIB. Program Y is more cutting edge, so it bundles the latest, unstable, GLIB and runs alongside Program X with no issue. In today's world, you don't have that ability without building the programs yourself. (Into entities separate from the core system I might add.) In theory, the programs could be compiled against a very specific revision of a library. In practicality, doing this results in minor dependency problems between different packages, meaning that you have to keep even MORE copies of the library around.
A package repository is a collection of programs, generally without much interaction between them except for dependencies. The fact that they are in a single repository does not increase their complication.
You just pointed out the caveat yourself: The packages have dependencies on each other, and thus form a monolithic system. Applications are regularly strewn about/usr and/usr/local rather than being handled as discrete components. The result is that pieces of software not tested directly against the repository (in all configurations, mind you) can cause conflicts over file versions, file names, and system configurations.
In a more componetized system, a given program would be self-contained, and programs would not have such complex interdependencies. Of course, that creates an issue where software would need to be able to target an expected configuration. If that configuration is unsuitable, then replacement components (for the given program ONLY) can be distributed inside the application.
If I'm not mistake, you've spent a great deal of time with UserLinux and its predecessors in an attempt to solve the matter of a standardized platform. My belief is that the market will always be one step ahead of standards bodies, and thus the standard needs to be set by the OS release. The versions of core libraries shouldn't be mucked with by users, only by officially released patches and upgrades. In that way, a stable system can emerge.
I'm, of course, still simplifying a lot of the details for brevity, but package managers are a definite part of the problem.
Also, a clarification. My work was intended to suggest a new distribution (or set of distributions) rather than a massive change across existing Linux systems. So I'm not really expecting Debian to change its packaging system suddenly. I only wish to point out that it's the achilles heal that lead up to this situation.
My first reaction to this entire situation is that, it's more complicated than it looks. On one hand, Mozilla doesn't want binaries being redistributed that they didn't build themselves. On the other hand, Debian wants to be able to handle source patches of their entire source tree. The result is that you get two competing ideals, both seemingly valid, creating this bit of a mess.
After stepping back for a moment, however, I realized that the problem isn't as complex as it seems. In fact, I think it highlights something I've been saying for a while: Package systems under Linux are a broken concept.
When I was working on the Linux Desktop Distribution of the Future article, I received quite a bit of criticism for calling the package management systems a major source of breakage. In the follow-up, I was forced to point out that complete system packaging creates a massive, monolithic code base:
There is no way to fully test a package repository. Since every package modifies the base system, the only way to prove that a package will work is to test it against every possible package configuration available! In case you're wondering, the math for that is P * P, where P is the number of packages available. A mere 100 packages could potentially result in 10,000 available configurations! That's a lot of potential for breakage! Now consider that most distros today have thousands of packages under their care, and the number is not declining.
Minor Correction: Reader Bradley Momberger has correctly pointed out that my math was a little screwy on this one. The correct forumla for the number of combinations is 2^P, which is actually quite a bit worse. 100 packages yields 1.26e30 possible combinations!
What we're seeing here is a legal extension of that same problem. By integrating the software into the codebase, Debian is attempting to take legal responsibility for the software. Yet the software provider (Mozilla) is already handling that responsibiity, and does not wish to give it up. On any other operating system, the binaries would get bundled (or not at all, if they're too untrustworthy) as a self-contained application, and the software provider would be allowed to continue handling updates. End of story.
In this case, Debian wants this software to be managed like all the other software they manage. Which means that taking responsibility becomes easier for them, rather than allowing the software producer to handle their own software. While this theoretically allows for a more cohesive system, that cohesiveness only goes as far as the packages checked into Debian's repository. Mozilla should be outside of that repository, but any software that's not in the repository is not well supported by the packaging system. Ergo, the process breaks down.
That's just my thoughts, anyway. I'm sure many will disagree. Loudly. And rudely. Oh well.:P
Slashdot Mirror
...the best ad EVER!
;)
Are You Keeping Up With The Commodore?
I guarantee you'll have that stupid jingle stuck in your head for DAYS! (BWHAHAH!) I even named my most recent blog article after it.
Kind of depends. I mean, you intend to make information public when you publicly post it on MySpace, right? So why would you be upset when people start looking for that information? Search engines used to be able to find personal webpages when those were all the craze.
The truth is, if you are concerned about privacy, don't make your personal matters public. Share only what you're willing to tell people, and hide things that should only be shared with a select few behind passwords. Then if someone breaks your security (even if it's fairly simple security), you at least have a case for your privacy being violated.
Am I the only one who can't get worked up about this exploit? I mean, I should be thinking, "this is happening because of X, we should do Y to fix it!" And yet, I just can't develop an opinion either way. It's not that I'm wrestling with myself, it's just that I don't care.
;)
Analyzing this, I think the reason is because the NVidia and ATI drivers are a PITA everywhere. By installing the drivers, you agree to destablize your system in exchange for the most incredible 3D (and 2D to a certain degree) performance. When Something Bad Happens(TM), you just sort of take it as coming with the territory.
It's sort of like hooking Nitro up to your car. Sure, your engine is more powerful than ever. But are you really all that surprised when you bust a valve, crack a ring, or do some other form of damage to your hotrod?
It would be nice if OSS drivers could be created. But it's probably not going to happen. NVidia won't open their drivers (ATI, doubly so) and the OSS community doesn't have enough info to recreate them. Thus I think the best bet is the Open Graphics Project. If they produce a viable 3D card alternative, you'll finally be able to chose between a stable (but slower) 3D card, or a high-performance, hotrod 3D Card. Take your pick to meet your needs.
Oh, and keep a firewall in front of your machine and the internet. Pipe all your X communications over SSH. Just good safety sense.
To a certain degree, I think you're already seeing the PSP gamers revolt. Quite a few of them have moved on to the Nintendo DS, which does NOT send out large system patches to fix "system issues". Especially when most of those "issues" are attempts to plug holes homebrewers are using.
In case you didn't notice, you are installing an operating system. Generally speaking, machines have always shipped with one OS to control the entire system. It is certainly *not* unreasonable for Microsoft to overwrite the MBR. Especially when they expect that their OS will be the only one. You'd have a hard time convincing a judge otherwise.
The fact that Microsoft hasn't improved this part of the install as more hobby OSes have showed up just goes to show how little they care about letting you use your hardware as you want to use it. But they are under no obligations, especially when the installer warns you to make backups before you run it.
Sounds like many game companies need to learn a newfangled idea (not really) known as "pipelining". You have various projects happening concurrently, with each project bubbling to the top as the necessary parts of the previous one are completed.
This would require good management, more normal working hours, and game development on a more normal schedule in order to happen. These things have been an antithesis to game companies, who have always struggled under tight timetables to get the game out while it's still technologically impressive. One is forced to wonder, though, is the technological death march really worth it? If your company's very existance is dependent on producing blockbuster after blockbuster, then you may be in a pretty bad position. No one can maintain a permanent streak, which is why you're probably only employed as far as the next game.
As much as I dislike EA, they do understand. (To a certain degree.) They have tons of projects in parallel, assuring that resources can be used and transferred as necessary. There's no "negative weight" holding the company down, save for post-launch vacations. If they would smooth out the development process, they could let everyone have lives so that they wouldn't need the post-launch vacations. Then their negative weight would reach pretty close to zero.
Games just aren't getting that much more impressive as time goes on. We're reaching areas of dimishing returns to where we can probably slow the pace in exchange for focusing on making good games that are fun, and have been properly QAed. There's no need for these last-minute additions or patches. Especially as the market revolts, and moves more and more toward console gaming. (Where proper QA is a requirement.)
Gamers want good games. Technology is only a canvas on which games are painted. It should not be the be-all-to-end-all of the game. If companies can reorganize around making high-quality games on more reasonable schedules, then I don't doubt that costs would lower and the products would improve.
My 2 pennies, anyway.
The double-standard of this "I'll look stupid" and "it's too much exercise" argument kills me. DDR was one of the most popular games in history (greatly improving PS2 & Dancepad sales), yet people worry about holding a remote control? The way I figure it, most couch warriors are used to holding remotes. There's not much on TV, so it's *flip* *flip* *flip*. Plenty of exercise for warming up to the Wii.
The one part of the article that really stuck out at me, though, was the comment that "large motions is how you have fun". I don't know how many people here have played Laser Tag-type games, but the sweeps and motions you make with your weapon are quite different when you're relaxed and when you're pumped. When you're relaxed, your reaction time is extremely slow. You tend to use extremely fine movements in attempts to aim, and may even tilt your wrist quite a bit. Yet when you're pumped, you work the floor, dodging, sweeping, and rolling. Your arm is primarily used for targetting, and you gain quite a bit of precision because of it.
It's just a lot more fun to get up and exercise. It releases a lot of good hormones that make you enjoy yourself. Besides, there's nothing quite like professionally strapping on your gear, just to have the guy next to you asking, "Have you ever played this before?" Oh yeah, bring it on.
Give the man a prize. This was exactly Jobs' point. He didn't say anything to suggest that he's opposed to the idea of wireless transfers, just that the Zune sucks at it. If the iPod were to add this feature, it would probably require you to cross the room, stand next to the girl (again, giving you that chance to talk to her), and very simply and painlessly initiate the file transfer. Knowing Apple, you'd probably be able to broadcast your current playlist to nearby iPods, allows you to pod-jack without even pod-jacking. Which would be in support of existing market needs (something which Apple excels at) rather than trying to force a feature onto the market that no one is asking for.
It's also an extremely well-known video game from PopCap games. Thus why I'm always confusing 'Zune' with 'Zuma'. :)
Ha! That's pretty funny. If you check the comments, you'll note that I've got other people doing it too! I wonder if the "misheard lyrics" sites will take this one?
Seriously, I need more coffee. I somehow always read "Zuma" when I see "Zune", and I just don't care enough about Microsoft's sinfully-ugly music player (at least at this hour of the morning) to get it right. I suppose that doesn't bode well for their marketing plans. Unless, of course, they simply try to crush the competition using their Windows monopoly. Microsoft would never do something like that, though....
[...]
Yeah, who am I kidding?
How is this news? Simple: By reading between the lines.
Every company delivers the same BS of, "We think our competitor provides no real challenge in the market." But if you actually listen to what they're saying, you can hear what they really think about it. Sort of like how Ballmer's denials of Google's importance always come across as, "I want to throw a f#@$ing CHAIR at those Google DEVELOPERS, DEVELOPERS, DEVELOPERS!"
I know a lot of Slashdotters hate iTunes for "DRM", "not HD(TV) quality", "too expensive", or whatever other B.S. excuse they can come up with, but...
You won't find that sort of business done at Microsoft. Their strategy is:
1. Announce a competing product with limitless fanfare. Doesn't matter if it sucks.
2. Slowly improve it until the market finds it semi-acceptable.
3. Leverage the Windows monopoly to CRUSH the competition.
Didn't you hear? You can only use iPods with a Mac. With Zuma, you can be compatible with the millions of Microsoft Vista machines, out of the box! Plus, you know you're getting Microsoft Quality(TM) and Support(TM) when you purchase a Zuma. Those other digital music companies could fold tomorrow, leaving you with no music and no refund. Only Microsoft products can provide you with a guaranteed safety net! </standard-Microsoft-bull>
You know, he's got a point. It might seem very impressive in a geeky way to Zuma a file across the room to the pretty girl (if you don't mind that I just used "Zuma" as a verb), but she is definitely not going to be impressed unless she's also a geek. You've also got the matter of the song being played in a vacuum, where your own thoughts and feelings on the tune are missing. Thus it holds no meaning. Besides, pod-jacking gives you a much better chance of being able to talk to that pretty girl.
Application Programmer Interface
Basically, a programatic way of accessing the functionality of Google's software.
I did a quicky review of Google's Spreadsheet when they released it six months ago. Since then, it would appear that Google has fixed some of my complaints. In particular:
:(
1. Cell borders have been added.
Umm... that's all I've got.
Everything else still appears to be an issue, including the calculation errors I spotted. And while Cell Borders have been added, there is no way to apply different styles. I'm pleased to see that Google is adding a new API for their "Office Suite", but they really need to fix some of these issues before they can be taken seriously.
Also, the continuing lack of charting is really sticking out. Data visualization is an important feature in a spreadsheet, whether you're preparing a market analysis or just balancing your household budget. The fact that plenty of web technologies exist to accomplish charting (SVG, round trip images, Flash, Java, etc.) only makes it stick out that much more. Now the API might allow external coders to help in this area, but so far I'm still not impressed.
No one has seen or heard of Enlightenment in so long, that he probably thought the icon was for "enlightening" topics. Either that, or he missed the button again.
;)
PLEASE Scuttlemonkey, don't fire him again! He's just trying to keep up with Slashdot tradition.
There is some truth to this. Nearly any coporate job demands long hours and tough working conditions, all so you can make a few extra bucks. Having both spouses working only exasperates the difficulties in spending time together. In a good relationship, both of you should naturally have a clear idea of what each other is up to. There's no need to give each other the first degree, or hang off each other. Just spending time together, talking a lot, and doing the things that couples do can go a long way toward saving the marriage. Unfortunately, this takes a LOT of effort, isn't very easy, and requires the commitment from both sides.
Having kids only puts more demands on your time. They need just as much of your time as your spouse does. That time, however, does NOT replace the alone time you need with your spouse! Just because you both spend time with your kid doesn't mean that you don't still need intimate time (physical, emotional, and otherwise) with each other. Just something to keep in mind.
BTW, check out my current sig for a geeky way to give your kids "daddy time".
I'm not aware of anyone who thinks that. VCs have been around for a very long time now, investing in multitudes of startups. Where do you think Silicon Valley's big tech companies like Apple, SGI, Sun, and others came from? They all had VC money to start their businesses with. The only difference is that we now live in a connected world where things like Venture Capital are more readily spoken about in open forums.
I hate to break it to you, but tech usually needs funding for development. Venture Capital is one way of getting that funding. It's especially important if your plans require that you build a large corporation to properly develop and exploit the technology.
There's a better than average chance that Venture Capital is partly to thank for your current job in technology. Especially if you're working on the more cutting edge developments rather than menial business-support tasks.
I'd just like to thank Mr. Gorman and Salil Deshpande for answering all our questions, and providing such useful and insightful information. These answers are some of the best I've ever seen on an Ask Slashdot. They are informative, straight to the point, and well researched. You may very well have enabled a new generation of entrepenuers.
Kudos!
I'm not disagreeing, just correcting that part of your recollection. If you remember, the missing day not only caused the massive economic damage you mentioned, but also nearly resulted in Scrooge loosing his third-world factory and being shot. The nephews had to use their Junior Woodchuck Guide on Solar Eclipses to prove that the day was actually Thursday. Then Launchpad had to clear the clouds so they could see the Eclipse before Scrooge was shot.
;D
After they proved the calendar date, they almost got a second allowance out of it, too!
Close, but not quite. The nephews really wanted a scooter, and there was a sale until Friday. Which meant that they needed to get their allowance on Thursday if they wanted to be able to afford it. Their shenanigans backfired when the store clerk was also convinced that it was Friday, and thus the sale was over.
Oops.
A dependency installed to the core system is a lot different than a program carrying a dependency externally. i.e. If I have two programs that rely on foo.dll and we presume that foo.dll is not a system file, then each program has its copy of foo.dll and life is good. Each program can be tested independently and can still confidently work together.
Now if both programs try to install the non-system DLL foo.dll into the core system, then they will produce a collision. Which could have a variety of outcomes:
1. The two versions are the same, no harm done.
2. The two versions are different but compatible, no harm done.
3. The two versions are wildly incompatible, so only one program will run.
4. The two versions are mildly incompatible, creating difficult to trace problems for one of the programs.
The Linux solution to this problem is to make one of the two foo.dlls into a system library, and both programs should play nice within the package management repository. Which might happen, or they might require incompatible versions which the packaging system won't allow to be installed.
What's needed is a distro configuration whereby the library is standardized as either being there with a specific version or not. If the developer knows the library will ship on the system and is of a compatible version, then he doesn't need to worry. He distributes his package and life is good. If he knows that the library does not ship on the system by default, then he should ship his own copy for use by his program only. Period, end of story. Any other programs using that library will have their own copy. If the library is popular enough, then the distro designers would make an informed decision about including the library in the next major platform upgrade.
This is all in the links I posted above.
Speak for yourself, there, cowboy.
LOGIC ERROR
Windows programs rarely install DLLs into the core system these days. Which means there's usually only a handful of configurations to test (mostly impacted by service packs and different Windows versions). This is the case because Microsoft cracked down on system-installed DLLs after consumers were having problems with DLL Hell. Today, DLL Hell is mostly a memory. (No comment on the stupidity of one ActiveX control per system.)
It's not monolithically coded, it's monolithically designed. The monolith is the design of the packaging system which forces the exact programs and configurations available.
Then what, exactly, are they doing by trying to deploy their own patches? Oh yes, taking responsibility.
By carrying it out to absurdity, you negate the purpose of the change in the first place. The idea is to have a stable core that can be targeted by all software. That core can be tested individually by each application. There will effectively be only one configuration that needs to be tested. Thus the problem of testing and deploying software can be cleanly pushed out to the software authors rather than the distributions.
Yet the common Linux design at the moment is to do the exact opposite. i.e. Worry so much about shared libraries that you force the user to manage obscure, difficult to find libraries that should probably be included with the program in the first place. There's nothing more frustrating than trying to track down a tiny little package on RPMFind because the distro doesn't support it in the repository, you can't find the original website for the life of you (probably buried somewhere on a homepage), the RPMs/DEBs/whatever you've downloaded are all incompatible with your OS configuration, but it's actually REQUIRED by this major third party program that should really be in the repository in the first place. On top of everything, some idjut is telling you to change distros just so you can get compatible packages for this one program, but then you won't be able to run the 9,999 other programs you need. *sigh*
The Debian repository is a long ways from the be-all to end-all of necessary software. Perhaps the most difficult segment for any repository is games. New OSS Linux games are appearing fairly regularly. The proliferation of this segment makes it difficult to keep the repository up to date, and the base system moves so quickly that a binary today is likely to not work within a few months. And since the supplemental packages are NEVER distributed with the software in the Linux world (funny how that's almost never a problem on Windows or Mac?), you have to go back to the "track down the compatible package" nightmare.
If you stick to Debian Stable, then that's generally true. Sort of, kinda, not really. In practice, -stable ends up lagging significantly behind the market, making it difficult to install recent software, while -unstable is exactly that: an unstable platform.
What you *want* is a stable core, and the ability to have either stable or unstable programs. Which means that program X over here might be perfectly happy with this year old GLIB. Program Y is more cutting edge, so it bundles the latest, unstable, GLIB and runs alongside Program X with no issue. In today's world, you don't have that ability without building the programs yourself. (Into entities separate from the core system I might add.) In theory, the programs could be compiled against a very specific revision of a library. In practicality, doing this results in minor dependency problems between different packages, meaning that you have to keep even MORE copies of the library around.
You just pointed out the caveat yourself: The packages have dependencies on each other, and thus form a monolithic system. Applications are regularly strewn about
In a more componetized system, a given program would be self-contained, and programs would not have such complex interdependencies. Of course, that creates an issue where software would need to be able to target an expected configuration. If that configuration is unsuitable, then replacement components (for the given program ONLY) can be distributed inside the application.
If I'm not mistake, you've spent a great deal of time with UserLinux and its predecessors in an attempt to solve the matter of a standardized platform. My belief is that the market will always be one step ahead of standards bodies, and thus the standard needs to be set by the OS release. The versions of core libraries shouldn't be mucked with by users, only by officially released patches and upgrades. In that way, a stable system can emerge.
I'm, of course, still simplifying a lot of the details for brevity, but package managers are a definite part of the problem.
Also, a clarification. My work was intended to suggest a new distribution (or set of distributions) rather than a massive change across existing Linux systems. So I'm not really expecting Debian to change its packaging system suddenly. I only wish to point out that it's the achilles heal that lead up to this situation.
After stepping back for a moment, however, I realized that the problem isn't as complex as it seems. In fact, I think it highlights something I've been saying for a while: Package systems under Linux are a broken concept.
When I was working on the Linux Desktop Distribution of the Future article, I received quite a bit of criticism for calling the package management systems a major source of breakage. In the follow-up, I was forced to point out that complete system packaging creates a massive, monolithic code base:
What we're seeing here is a legal extension of that same problem. By integrating the software into the codebase, Debian is attempting to take legal responsibility for the software. Yet the software provider (Mozilla) is already handling that responsibiity, and does not wish to give it up. On any other operating system, the binaries would get bundled (or not at all, if they're too untrustworthy) as a self-contained application, and the software provider would be allowed to continue handling updates. End of story.
In this case, Debian wants this software to be managed like all the other software they manage. Which means that taking responsibility becomes easier for them, rather than allowing the software producer to handle their own software. While this theoretically allows for a more cohesive system, that cohesiveness only goes as far as the packages checked into Debian's repository. Mozilla should be outside of that repository, but any software that's not in the repository is not well supported by the packaging system. Ergo, the process breaks down.
That's just my thoughts, anyway. I'm sure many will disagree. Loudly. And rudely. Oh well.