SFW, as long as you aren't drinking anything you wouldn't want to spit up on your keyboard when you're reading it, otherwise your employer's IT department might not be happy about having to deal with the results of your spit-take.
Given that this is a desktop environment for FreeBSD, atop which PC-BSD is based, not Linux (it might also work on Linux, but I presume that's not the primary goal), that's not relevant to this article (and also involves labeling a large number of significant and successful companies "insane", but that's probably your intent).
The PC-BSD project is developing a new open source (BSD license) desktop environment from scratch. The name of the project is Lumina and it will be based around the Qt toolkit
Unless there's a surfing spot at Yosmite that I'm not aware of, I doubt it.
Who at Apple said that the new naming convention is "California surfing sites" rather than "California locations"? We only have one data point so far, and that's insufficient to conclude that the locations will all be surfing sites (or named after dogs or located in San Mateo or Santa Clara county or...).
With open-source software, a monoculture isn't that bad a thing, as the Heartbleed exploit has shown. When something bad is discovered, people jump on it immediately and come up with a fix, which is deployed very very quickly (and free of charge, I might add). How fast was a fix available for Heartbleed? Further, people will go to greater lengths to make sure it doesn't happen again. Look at the recent efforts to rewrite OpenSSL, and the fork that was created from it.
"It" in "it doesn't happen again" being "a monoculture"? If you have a monoculture, a fork destroys it unless a new monoculture forms from the fork (i.e., if the forked-from project loses most of its market share).
The TLDR is I chose the 'code' option after testing the available options and finding it sucks less.
I use <code> too, if I'm posting code. Well, actually, I use <ecode>, because <code> appears not to honor line breaks and <ecode> appears not to honor indentation, and, for code, the latter sucks less than the former. Neither of them appear to provide me with any advantages if I'm just posting text.
The grandparent's signature line suggests he or she is making some sort of point about Javascript.
(Any objections containing the letters "e", "c", "m", and "a", regardless of capitalization, in sequence must be accompanied by an indication of why Javascript is different from ECMAscript in this context.)
Um, you pretty much described EXACTLY what Barnes and Noble tried to do, and it didn't really work out all that well for them(the execution may have left something to be desired but).
But TFA seems to be talking more about independent bookstores than the "brick-and-mortar" chain bookstores that gave the independent bookstores trouble a while ago.
they need to build in an x86 emulation layer to make these more attractive to gp programmers... if they had that I may be able to make them work with the drone I'm designing for i/o and avionics control but I do not feel like rewriting the whole damn code base to run on these frankenchips.
You're programming your drone in assembler language?
My second computer was a 360. I began life coding Fortran IV on one of the 360's immediate predecessors, the IBM 1410. At the time, mainframes occupied two distinct categories: "business" machines like the 1410, which organized data as individual 6-bit bytes, and "scientific" mainframes like the 7090 series, which saw data as 32-bit integers and floats.
36-bit. There was also the 1620, which organized data as 4-bit decimal digits (with an extra flag bit and a parity bit); a character took two digits.
Over twenty years ago there were computers that hardware and software that were designed to work together. At least two of these systems had extra tag bits in memory that defined the memory contents. Specifically I am talking about Symbolics Lisp Machines and Burroughs Large Systems that natively ran Algol.
Or, rather, ran an instruction set with some features oriented towards ALGOL. Other languages could also be, and were, translated to that instruction set.
Do you have a piece of source code to support your claims?
No. Do you have a piece of source code to prove that NT-family versions of Windows are DOS-based? The "Inside Windows NT" books say that the NT kernel-mode code has a very much non-DOS structure.
Because unless proven otherwise, Windows is still a crap patchwork.
An OS can be a "crap patchwork" without being based on DOS.
Other minds think there's still DOS in the core of Windows, rather than a bag on the side to run old DOS programs, sort of like the VDM in Wine. Srsly, the late '90's called, they want their "Windows is still a hack on top of DOS" meme back.
Well, that link looks like a forum of fanboys rather than a forum of experts (for one thing, they appear to be confusing EM64T, the Intel 64-bit x86 instruction set, with the initial implementations; the ISA is true 64-bit, even if the initial implementations don't have 64-bit data paths, just as an IBM System 360/30 was a 32-bit computer even though it had 8-bit data paths internally and did 32-bit arithmetic a byte at a time).
About all the forum posters say about Conroe is "seems to apply since conroe as intel fans will tell you KILLS/rapes/pilleges amd in 32bit, but in 64bit they just shrug and ignore the fact that it dosnt perform as well as conroe 32bit perf would emply."; nobody on the forum appears to have actually looked at the die layout as the guy on chip-architect.com did.
It was approximately 2010. I asked about EM64T while participating in a build event at an Intel convention in Chicago. They called corporate and confirmed.
So, in 2010, they'd either be Core 2 (not inconceivable, as per my other reply, if the Core 2 design started out as 32-bit and changed to 64-bit late in the game) or Nehalem (less likely, as by that time I'd expect them to have a design that started out as 64-bit, unless their design pipeline was as deep as Pentium 4's pipeline:-)).
The machine that I walked away with used a Mini-ITX board, had an I5 and HD4000 graphics. Perhaps things have changed since then.
It was true for the first generation or two of Intel chips that supported AMD's 64-bit extensions. It hasn't been true for quite a while though.
So that'd be the 64-bit Pentium 4s (perhaps not surprising, as it was initially a 32-bit microarchitecture, and fully widening it to do 64 bits of arithmetic at the time might've been more work than they wanted to do) and the Core 2 (more surprising, as that microarchitecture was released in 64-bit chips from Day One, but maybe the design work started with a 32-bit chip and the 64-bitness was added at the last minute).
So I can believe it for the 64-bit Pentium 4s; is there any solid information indicating that it was true of the Core 2 processors?
TCP is for reliable in order transmission/reception of octects.
...and standardizes nothing about the content of those octets, so, as you suggest, TCP, by itself, is insufficient to "[simplify] data sharing across disparate applications in enterprise, cloud, and mobile devices".
You have to appreciate the irony that they find a new symbiotic fungus with clear health benefits and immediately try and use it to develop a novel way to kill fungus.
And the health benefit is that it puts out a substance that, err, umm, kills other fungus species, so "[killing] fungus" - or, to state it in a more accurate fashion, "killing other fungus species - is the clear health benefit.
So this is not any more ironic than, say, introducing a predatory mammal species to an ecosystem to cut down on the population of another mammal species.
They are against evolution, and in general science, because science is all at odds with one of the most important fundamental "virtue" of Christian: faith.
This post isn't about Christianity, as can be inferred from the title.
SFW, as long as you aren't drinking anything you wouldn't want to spit up on your keyboard when you're reading it, otherwise your employer's IT department might not be happy about having to deal with the results of your spit-take.
I thought that Qt is available under a BSD license as well
Nope.
I learned today why no sane company uses linux
Given that this is a desktop environment for FreeBSD, atop which PC-BSD is based, not Linux (it might also work on Linux, but I presume that's not the primary goal), that's not relevant to this article (and also involves labeling a large number of significant and successful companies "insane", but that's probably your intent).
The PC-BSD project is developing a new open source (BSD license) desktop environment from scratch. The name of the project is Lumina and it will be based around the Qt toolkit
OK, so they're developing a BSD-licensed desktop environment atop a GPL v3/LGPL v2.1-licensed toolkit, right?
Unless there's a surfing spot at Yosmite that I'm not aware of, I doubt it.
Who at Apple said that the new naming convention is "California surfing sites" rather than "California locations"? We only have one data point so far, and that's insufficient to conclude that the locations will all be surfing sites (or named after dogs or located in San Mateo or Santa Clara county or...).
With open-source software, a monoculture isn't that bad a thing, as the Heartbleed exploit has shown. When something bad is discovered, people jump on it immediately and come up with a fix, which is deployed very very quickly (and free of charge, I might add). How fast was a fix available for Heartbleed? Further, people will go to greater lengths to make sure it doesn't happen again. Look at the recent efforts to rewrite OpenSSL, and the fork that was created from it.
"It" in "it doesn't happen again" being "a monoculture"? If you have a monoculture, a fork destroys it unless a new monoculture forms from the fork (i.e., if the forked-from project loses most of its market share).
Now that aside, notice you are talking about explicitly tagging your text, which I am not doing.
And which I always do. Different strokes for different folks.
The TLDR is I chose the 'code' option after testing the available options and finding it sucks less.
I use <code> too, if I'm posting code. Well, actually, I use <ecode>, because <code> appears not to honor line breaks and <ecode> appears not to honor indentation, and, for code, the latter sucks less than the former. Neither of them appear to provide me with any advantages if I'm just posting text.
The grandparent's signature line suggests he or she is making some sort of point about Javascript.
(Any objections containing the letters "e", "c", "m", and "a", regardless of capitalization, in sequence must be accompanied by an indication of why Javascript is different from ECMAscript in this context.)
Um, you pretty much described EXACTLY what Barnes and Noble tried to do, and it didn't really work out all that well for them(the execution may have left something to be desired but).
Other big-box book retailers haven't succeeded at that, either.
But TFA seems to be talking more about independent bookstores than the "brick-and-mortar" chain bookstores that gave the independent bookstores trouble a while ago.
they need to build in an x86 emulation layer to make these more attractive to gp programmers ... if they had that I may be able to make them work with the drone I'm designing for i/o and avionics control but I do not feel like rewriting the whole damn code base to run on these frankenchips.
You're programming your drone in assembler language?
My second computer was a 360. I began life coding Fortran IV on one of the 360's immediate predecessors, the IBM 1410. At the time, mainframes occupied two distinct categories: "business" machines like the 1410, which organized data as individual 6-bit bytes, and "scientific" mainframes like the 7090 series, which saw data as 32-bit integers and floats.
36-bit. There was also the 1620, which organized data as 4-bit decimal digits (with an extra flag bit and a parity bit); a character took two digits.
Over twenty years ago there were computers that hardware and software that were designed to work together. At least two of these systems had extra tag bits in memory that defined the memory contents. Specifically I am talking about Symbolics Lisp Machines and Burroughs Large Systems that natively ran Algol.
Or, rather, ran an instruction set with some features oriented towards ALGOL. Other languages could also be, and were, translated to that instruction set.
But what about those of us who want to rip Betamax, Casettes, Grammerphone Records and VHS?
Hell, what about Edison Cylinders?
Srsly, the late '90's called, they want their "Windows is still a hack on top of DOS" meme back.
You're right. Windows X is a hack on top of Windows 1 ... X - 1.
OK, if "Windows NT 3.1" is Windows X, what's Windows X - 1?
Do you have a piece of source code to support your claims?
No. Do you have a piece of source code to prove that NT-family versions of Windows are DOS-based? The "Inside Windows NT" books say that the NT kernel-mode code has a very much non-DOS structure.
Because unless proven otherwise, Windows is still a crap patchwork.
An OS can be a "crap patchwork" without being based on DOS.
Great minds think alike. Came here to post this.
Yes, great minds think alike.
Other minds think there's still DOS in the core of Windows, rather than a bag on the side to run old DOS programs, sort of like the VDM in Wine. Srsly, the late '90's called, they want their "Windows is still a hack on top of DOS" meme back.
The first gen Conroe Core 2 chips apparently used a similar design trick. It was after all primarily a return to the Pentium III core with a die shrink and some tweaks to support EMT64. Intel was scrambling to recover from the wasteful detour of the Pentium IV. It might have taken them one more gen before the redesign for full 64-bit ALUs - I don't remember anymore.
Well, that link looks like a forum of fanboys rather than a forum of experts (for one thing, they appear to be confusing EM64T, the Intel 64-bit x86 instruction set, with the initial implementations; the ISA is true 64-bit, even if the initial implementations don't have 64-bit data paths, just as an IBM System 360/30 was a 32-bit computer even though it had 8-bit data paths internally and did 32-bit arithmetic a byte at a time).
The first posting linked to an article at chip-architect.com about the 64-bit Pentium 4, and that's the posting that contains the actual analysis of the 64-bit Pentium 4 (as opposed to the shouting on the forum).
About all the forum posters say about Conroe is "seems to apply since conroe as intel fans will tell you KILLS/rapes/pilleges amd in 32bit, but in 64bit they just shrug and ignore the fact that it dosnt perform as well as conroe 32bit perf would emply."; nobody on the forum appears to have actually looked at the die layout as the guy on chip-architect.com did.
It was approximately 2010. I asked about EM64T while participating in a build event at an Intel convention in Chicago. They called corporate and confirmed.
So, in 2010, they'd either be Core 2 (not inconceivable, as per my other reply, if the Core 2 design started out as 32-bit and changed to 64-bit late in the game) or Nehalem (less likely, as by that time I'd expect them to have a design that started out as 64-bit, unless their design pipeline was as deep as Pentium 4's pipeline :-)).
The machine that I walked away with used a Mini-ITX board, had an I5 and HD4000 graphics. Perhaps things have changed since then.
I rather suspect they have.
It was true for the first generation or two of Intel chips that supported AMD's 64-bit extensions. It hasn't been true for quite a while though.
So that'd be the 64-bit Pentium 4s (perhaps not surprising, as it was initially a 32-bit microarchitecture, and fully widening it to do 64 bits of arithmetic at the time might've been more work than they wanted to do) and the Core 2 (more surprising, as that microarchitecture was released in 64-bit chips from Day One, but maybe the design work started with a 32-bit chip and the 64-bitness was added at the last minute).
So I can believe it for the 64-bit Pentium 4s; is there any solid information indicating that it was true of the Core 2 processors?
Intel calls EMT64 64 bits
Intel hasn't called it EM64T in years. It's now "Intel 64".
when it is just 32 bits on each 1/2 of the clock cycle.
Please provide a reliable source for your assertion that all Intel 64 processors have 32-bit data paths internally.
TCP is for reliable in order transmission/reception of octects.
...and standardizes nothing about the content of those octets, so, as you suggest, TCP, by itself, is insufficient to "[simplify] data sharing across disparate applications in enterprise, cloud, and mobile devices".
You have to appreciate the irony that they find a new symbiotic fungus with clear health benefits and immediately try and use it to develop a novel way to kill fungus.
And the health benefit is that it puts out a substance that, err, umm, kills other fungus species, so "[killing] fungus" - or, to state it in a more accurate fashion, "killing other fungus species - is the clear health benefit.
So this is not any more ironic than, say, introducing a predatory mammal species to an ecosystem to cut down on the population of another mammal species.
They are against evolution, and in general science, because science is all at odds with one of the most important fundamental "virtue" of Christian: faith.
This post isn't about Christianity, as can be inferred from the title.
Actually, no, it's Businessweek, but
You're reading a publication intended for wannabe CEOs and pointy-haired managers. It's not Engineering Weekly, so give it a rest.
might still be the case.