Re:Use Anti-Plagerism Software Instead of Auditing
on
ReactOS Code Audit
·
· Score: 1
They admitted that individual developers have had contact with the source code, and it's unclear to me if these developers were core members of the project or just casual committers. I get your point that it's impossible to audit without knowing what to look for, but it doesn't seem to me like it'd be a good idea to have this as a step in an audit process that's officially being lead by the project itself. Sure, someone else could do it unofficially, away from the official audit, but didn't your first post call this out as something that'd need to be integrated into the audit itself?
Just one more detail. In any case, continually checking the full code for references to the leaked source code seems to me to imply - like you say - advertised access to the leaked code. The committed code that prompted the audit in the first place *could* have been someone reading code off of someone else's screen - being exposed to the source code and not actually in possession of it. I don't see how the worst case scenario (project officially in possession of leaked code vs. individual developers exposed to leaked code, or maybe even legit code under some Microsoft arrangements) is not going to make the audit one magnitude worse if you'd want to avoid Microsoft's lawyers.
Re:Use Anti-Plagerism Software Instead of Auditing
on
ReactOS Code Audit
·
· Score: 1
I still can't shake the idea that admitting that you have the leaked code in the first place is a bad idea, regardless of if you're a developer or just responsible for running the test, or if you're in the US or not. And I don't think it'd sit well with an audit effort to indirectly rely on the code you're supposed to not copy, even if they don't openly or officially support it.
Re:Use Anti-Plagerism Software Instead of Auditing
on
ReactOS Code Audit
·
· Score: 2, Insightful
Well, that would mean they'd have to 'officially' possess the leaked code, which would mean Microsoft's lawyers would be all over them at the drop of a hat.
During the past six months they've had a few server switches and almost constant rejiggering, and they're just settling in with a new bunch of servers, partly because of hardware failure. My assessment of the whole deal is that poor programming, actual scalability or design hasn't been the problem as much as growing pains (more users AND abusers like moronic spiders clogging bandwidth and stealing capacity), power outages and hardware just flat out not working. Although I don't rely on their service myself or use it more than, say, once quarterly, they're a competent bunch, and I fully trust that it will all work itself out in the end.
Readthose first. It seemed at the time of the publication that the XHTML 2.0 team were making all the mistakes of the designers of HTML 3.0 - creating teh perfekt markup language, instead of contributing called-for improvements, even if the two overlap a lot to our benefit. And I don't think that's changed. (I don't mean to disparage the many good changes in XHTML 2.0, but I ultimately think that their goal (stripping down and semantically cleansing XHTML 1.1?) is a different one than mine, and that that means we're not getting the improvements we want.)
We get it that embedding a good HTML rendering engine adds user value. Apple also got that, and implemented WebKit right into the system. HOWEVER, on the OS X side of the fence, the Finder doesn't rely on it, and it's not hinged with Safari. Software Update (the Windows Update counterpart) is a solitary app with a table for a list of updates, a rich text field for the description and another rich text field for license agreements in a secondary dialog.
Microsoft, if you can hear me, a standards-compliant IE engine embedded into Windows *would* be good (for the purposes of a short post, I'm leaving the but-IE7-will-not-be-standards-compliant, lock-in and monopoly issues as an exercise for the reader here) but it does NOT mean that it's fucking neat to build it into all of your apps - or in extreme cases build apps on top of it or in it where it's not at all needed. It also doesn't make for a good time when the next vulnerability in your rendering engine comes along.
I mean we're going to have one guy (Jobs) essentially controlling two companies that will between them produce the content, the distribution network, the playback codec and the playback device.
The only playback codecs Apple make that are somewhat relevant to this is Pixlet and Apple Lossless, and both are high-quality codecs that might make sense inside the studios but will never be used to encode any content distributed by the network to the playback device.
The FairPlay DRM, however, is proprietary, but that's not a codec. And both H.264 and AAC are supported parts of the independent MPEG-4 standard. Nice try though.
(And again, like someone else said, "You mean, like Sony?")
Disney already carry the rights to do follow-ups to all films released by Pixar through Disney (basically all films from "Toy Story" through this year's "Cars") so they could already make trashy sequels. Would you rather have Pixar on this staff or off it?:)
That said, I also think Pixar was doing just fine on their own, although I also think they were in desperate need for a distribution partner with the Disney contract ending after "Cars".
MacBook Pro looks, quacks and waddles like a duck - specifically, a retro-fit juiced up model of the old duck, so to speak.
They did it before with Kanga when the G3 came out and they wanted to use it in the PowerBook, and this looks like much the same thing. I won't exactly bet you a thousand bucks that FireWire 800 is gonna come back on newer models, but S-Video, DVD+-RW DL and resolution are all gimmes, and Steve Jobs went on the record as saying that the battery life will be 'comparable' to the PowerBook G4 in some magazine the other day.
In short: don't base your opinion on a rushed-to-market "frist psot"-like machine.
With all respect to Apple's turn-around time... They inserted an intermediary page and a cookie requirement (presumably) on a cluster of servers they control. Microsoft had to try to test every Windows version/language/service pack combo with a large array of software that could be affected and then push it out through a number of channels. As far as scope and danger goes, you're comparing a somewhat bemused amoeba (never an actual flaw, but a badly documented feature) to a pissed off avian flu here.:)
You spelled "business" "busines". Does that mean that I'm free to not take you seriously? And furthermore, if you were getting paid for posting that comment, would that mean that you suddenly would *not* have overlooked it?
I agree as much as anyone else that the spelling could be better. (I'm fairly anally retentive about this myself.) However, I also tremendously agree with CmdrTaco when he says that it's not the most important thing in the world. If given a choice, I would much rather complain about, say, any quality problems the story selection process might have. Furthermore, how many stories do you think are prime, non-dupe (stop laughing) candidates each day but don't get posted? My guess is that CmdrTaco and friends clean them up, too, before they make a decision to not post it. If there are a lot of those, minutes *could* add up.
But I also must say that I think every spelling error that's pointed out should be fixed, regardless of whether it's ridiculously obvious or not.
(How do I indicate something's been updated or deleted without triggering duplicate entries in everyone's feed reader?)
You change the entry's summary or other content and keep the same GUID. As there's no way to determine what's a GUID in RSS 2.0 this week (because Dave Winer controls that, and he doesn't mind retconning the semantics of the spec while not actually explaining it in the spec but in weblog posts), a wise course of action would be to use Atom.
Take my word for it - if you're doing GUI app development, Mac OS X in general and Cocoa in particular is where it's at. Cocoa is like a proven, tested.NET-like framework, and it has matured to the point that some of the stuff it can do for you really is unprecedented anywhere else. Look up Core Data and Cocoa Bindings in specific.
Re:There's also the "form" factor
on
New iMac disassembled
·
· Score: 4, Informative
As an owner of a PowerBook G4 1.5GHz (which amazingly is not only, predictably, obsolete at a year and three weeks, but was in fact more or less obsolete when it shipped; that the MacBook Pro is reportedly only 4-5x faster in benchmarks is surprising) I'll have to disagree.
I'm a programmer. OS X has some of the best tools I've ever used, and it gives me access to both tools I used before (most of the unixy goodness like the scripting languages and simple, focused command line tools) and now continue to use, and to some completely awesome new tools (Cocoa). This isn't me being a zealot (I'm presumably much more annoying when I'm a zealot), it's just facts.
It's true that lots of people who are 'in an artistic field' appreciate Macs too, because it's what they've been using all these years. But I, as a programmer, find that I write apps much easier and that the other tools in my toolbox are plenty and good. I like the industrial design (swap out with 'pwetty boxes' if you seriously think they're the same thing) as much as anyone, but aside from a fleeting fascination with it, it's not why I bought it - I bought it because of an awesome OS and some very good tools. And so far, I have not been let down.
Good points. The only reason I'm suggesting this is because there are some features in.Mac - most of them features in iLife or OS X that Apple have chosen to make.Mac-only features out of, by the way - that could be worth their while. Easy synchronizing, "photocasting" and so on. $99 just to enable them is highway robbery, and if they could get it down to mere mugging, that would feel a bit better.
Yes, it's flamebait. I'd wager most of us iPod owners - although it's hard and wrong to generalize - don't consider other players 'lesser players', just players that don't do it for us personally. But that's mostly a function of taste, not universal excellence. In short, ignore the dumb turn of phrase.
How so? By connecting iLife and.Mac? Have you used iLife apps lately? The tie-ins are massive - my proposal just makes the connection a bit more opaque and the whole deal cheaper.
Plain.Mac (1 year), or plain iLife: $60. .Mac (1 year) and iLife: $90. .Mac (1 year) when bought with any new Mac: $30 first year.
The baseline bandwidth and space would be lower, and most people who wanted to really get something out of it could pay $30 extra per year to get up to today's standard. This seems like a better solution as currently a lot of people don't want everything.Mac has to offer.
I think "Core" is meant to tie into the new philosophy that Intel is supposedly a "platforms" company - i.e. "Here's what's at the Core of [Centrino/Viiv/foo]." and not processor cores as such. Point taken though.
Slashdot Mirror
They admitted that individual developers have had contact with the source code, and it's unclear to me if these developers were core members of the project or just casual committers. I get your point that it's impossible to audit without knowing what to look for, but it doesn't seem to me like it'd be a good idea to have this as a step in an audit process that's officially being lead by the project itself. Sure, someone else could do it unofficially, away from the official audit, but didn't your first post call this out as something that'd need to be integrated into the audit itself?
Just one more detail. In any case, continually checking the full code for references to the leaked source code seems to me to imply - like you say - advertised access to the leaked code. The committed code that prompted the audit in the first place *could* have been someone reading code off of someone else's screen - being exposed to the source code and not actually in possession of it. I don't see how the worst case scenario (project officially in possession of leaked code vs. individual developers exposed to leaked code, or maybe even legit code under some Microsoft arrangements) is not going to make the audit one magnitude worse if you'd want to avoid Microsoft's lawyers.
I still can't shake the idea that admitting that you have the leaked code in the first place is a bad idea, regardless of if you're a developer or just responsible for running the test, or if you're in the US or not. And I don't think it'd sit well with an audit effort to indirectly rely on the code you're supposed to not copy, even if they don't openly or officially support it.
Well, that would mean they'd have to 'officially' possess the leaked code, which would mean Microsoft's lawyers would be all over them at the drop of a hat.
No, look at the scale of the chart.
Since its launch, and especially during the latest six months or so, the site has been growing at a great pace - exponential growth is actually an apt term.
During the past six months they've had a few server switches and almost constant rejiggering, and they're just settling in with a new bunch of servers, partly because of hardware failure. My assessment of the whole deal is that poor programming, actual scalability or design hasn't been the problem as much as growing pains (more users AND abusers like moronic spiders clogging bandwidth and stealing capacity), power outages and hardware just flat out not working. Although I don't rely on their service myself or use it more than, say, once quarterly, they're a competent bunch, and I fully trust that it will all work itself out in the end.
Read those first. It seemed at the time of the publication that the XHTML 2.0 team were making all the mistakes of the designers of HTML 3.0 - creating teh perfekt markup language, instead of contributing called-for improvements, even if the two overlap a lot to our benefit. And I don't think that's changed. (I don't mean to disparage the many good changes in XHTML 2.0, but I ultimately think that their goal (stripping down and semantically cleansing XHTML 1.1?) is a different one than mine, and that that means we're not getting the improvements we want.)
My money's with, and my faith's in, HTML5.
We get it that embedding a good HTML rendering engine adds user value. Apple also got that, and implemented WebKit right into the system. HOWEVER, on the OS X side of the fence, the Finder doesn't rely on it, and it's not hinged with Safari. Software Update (the Windows Update counterpart) is a solitary app with a table for a list of updates, a rich text field for the description and another rich text field for license agreements in a secondary dialog.
Microsoft, if you can hear me, a standards-compliant IE engine embedded into Windows *would* be good (for the purposes of a short post, I'm leaving the but-IE7-will-not-be-standards-compliant, lock-in and monopoly issues as an exercise for the reader here) but it does NOT mean that it's fucking neat to build it into all of your apps - or in extreme cases build apps on top of it or in it where it's not at all needed. It also doesn't make for a good time when the next vulnerability in your rendering engine comes along.
Seriously, knock it off.
I mean we're going to have one guy (Jobs) essentially controlling two companies that will between them produce the content, the distribution network, the playback codec and the playback device.
The only playback codecs Apple make that are somewhat relevant to this is Pixlet and Apple Lossless, and both are high-quality codecs that might make sense inside the studios but will never be used to encode any content distributed by the network to the playback device.
The FairPlay DRM, however, is proprietary, but that's not a codec. And both H.264 and AAC are supported parts of the independent MPEG-4 standard. Nice try though.
(And again, like someone else said, "You mean, like Sony?")
Disney already carry the rights to do follow-ups to all films released by Pixar through Disney (basically all films from "Toy Story" through this year's "Cars") so they could already make trashy sequels. Would you rather have Pixar on this staff or off it? :)
That said, I also think Pixar was doing just fine on their own, although I also think they were in desperate need for a distribution partner with the Disney contract ending after "Cars".
MacBook Pro looks, quacks and waddles like a duck - specifically, a retro-fit juiced up model of the old duck, so to speak.
They did it before with Kanga when the G3 came out and they wanted to use it in the PowerBook, and this looks like much the same thing. I won't exactly bet you a thousand bucks that FireWire 800 is gonna come back on newer models, but S-Video, DVD+-RW DL and resolution are all gimmes, and Steve Jobs went on the record as saying that the battery life will be 'comparable' to the PowerBook G4 in some magazine the other day.
In short: don't base your opinion on a rushed-to-market "frist psot"-like machine.
With all respect to Apple's turn-around time... They inserted an intermediary page and a cookie requirement (presumably) on a cluster of servers they control. Microsoft had to try to test every Windows version/language/service pack combo with a large array of software that could be affected and then push it out through a number of channels. As far as scope and danger goes, you're comparing a somewhat bemused amoeba (never an actual flaw, but a badly documented feature) to a pissed off avian flu here. :)
You spelled "business" "busines". Does that mean that I'm free to not take you seriously? And furthermore, if you were getting paid for posting that comment, would that mean that you suddenly would *not* have overlooked it?
I agree as much as anyone else that the spelling could be better. (I'm fairly anally retentive about this myself.) However, I also tremendously agree with CmdrTaco when he says that it's not the most important thing in the world. If given a choice, I would much rather complain about, say, any quality problems the story selection process might have. Furthermore, how many stories do you think are prime, non-dupe (stop laughing) candidates each day but don't get posted? My guess is that CmdrTaco and friends clean them up, too, before they make a decision to not post it. If there are a lot of those, minutes *could* add up.
But I also must say that I think every spelling error that's pointed out should be fixed, regardless of whether it's ridiculously obvious or not.
(How do I indicate something's been updated or deleted without triggering duplicate entries in everyone's feed reader?)
You change the entry's summary or other content and keep the same GUID. As there's no way to determine what's a GUID in RSS 2.0 this week (because Dave Winer controls that, and he doesn't mind retconning the semantics of the spec while not actually explaining it in the spec but in weblog posts), a wise course of action would be to use Atom.
Can your computer do what you want it to? If so, it's not obsolete.
Yes, that was kind of my point, hence the reference to the parent.
Take my word for it - if you're doing GUI app development, Mac OS X in general and Cocoa in particular is where it's at. Cocoa is like a proven, tested .NET-like framework, and it has matured to the point that some of the stuff it can do for you really is unprecedented anywhere else. Look up Core Data and Cocoa Bindings in specific.
As an owner of a PowerBook G4 1.5GHz (which amazingly is not only, predictably, obsolete at a year and three weeks, but was in fact more or less obsolete when it shipped; that the MacBook Pro is reportedly only 4-5x faster in benchmarks is surprising) I'll have to disagree.
I'm a programmer. OS X has some of the best tools I've ever used, and it gives me access to both tools I used before (most of the unixy goodness like the scripting languages and simple, focused command line tools) and now continue to use, and to some completely awesome new tools (Cocoa). This isn't me being a zealot (I'm presumably much more annoying when I'm a zealot), it's just facts.
It's true that lots of people who are 'in an artistic field' appreciate Macs too, because it's what they've been using all these years. But I, as a programmer, find that I write apps much easier and that the other tools in my toolbox are plenty and good. I like the industrial design (swap out with 'pwetty boxes' if you seriously think they're the same thing) as much as anyone, but aside from a fleeting fascination with it, it's not why I bought it - I bought it because of an awesome OS and some very good tools. And so far, I have not been let down.
Good points. The only reason I'm suggesting this is because there are some features in .Mac - most of them features in iLife or OS X that Apple have chosen to make .Mac-only features out of, by the way - that could be worth their while. Easy synchronizing, "photocasting" and so on. $99 just to enable them is highway robbery, and if they could get it down to mere mugging, that would feel a bit better.
Prove him wrong.
Yes, it's flamebait. I'd wager most of us iPod owners - although it's hard and wrong to generalize - don't consider other players 'lesser players', just players that don't do it for us personally. But that's mostly a function of taste, not universal excellence. In short, ignore the dumb turn of phrase.
How so? By connecting iLife and .Mac? Have you used iLife apps lately? The tie-ins are massive - my proposal just makes the connection a bit more opaque and the whole deal cheaper.
Here's a proposal:
Plain .Mac (1 year), or plain iLife: $60.
.Mac (1 year) and iLife: $90.
.Mac (1 year) when bought with any new Mac: $30 first year.
The baseline bandwidth and space would be lower, and most people who wanted to really get something out of it could pay $30 extra per year to get up to today's standard. This seems like a better solution as currently a lot of people don't want everything .Mac has to offer.
Depends on how you define "refreshment". :)
Why's that bad? They didn't say February 1st, they said February. I would have been ecstatic if it had been February 27th.
In other words: In Korea, only old people use PCs.
(Come on! Someone had to say it!)
I think "Core" is meant to tie into the new philosophy that Intel is supposedly a "platforms" company - i.e. "Here's what's at the Core of [Centrino/Viiv/foo]." and not processor cores as such. Point taken though.