declarations to import specific std:: types in your header files, which is where you really need to avoid namespace clashes which may occur down the line as users combine your libraries with other peoples', but you can safely use
using namespace std;
declarations in the body of your code, since this isn't going to be #included anywhere else
Since there's a lot of confusion above this post about the relationship between ARM, Intel, Compaq, DEC and Uncle Tob Cobbleigh and all, a clarification.
Intel bought the StongARM stuff from DEC / Compaq
No they didn't, they licenced the design from ARM plc, as did DEC/Compaq
Yes it IS an ARM processor, but not an INTEL one. It is made by a British Company CALLED ARM. You can find them at: www.arm.com They compete with INTEL in the same space with this CPU.
Sorry, wrong again. ARM don't make anything tangible: they're an IP company pure and simple. They license their chip designs to anyone who's prepared to pay the licensing costs. At the moment, this is pretty much every hardware/white-goods company out there.
A little bit of history: ARM is a spin-off of the late and lamented Acorn Computers. In the early to mid-80's, Acorn (who had a very nice range of 6502 based micros - the Tube, a shared-nothing multiprocessing architecture, was a very groovy thing to have in a £400 micro) realised that these processors weren't going anywhere and the alternatives didn't fit their idea of what a quality CPU should do (this was in the days when RISC was the next big thing but the only commercially available RISC processors cost the earth...), so they decided to design their own RISC architecture and develop a processor and chipset.
Some years later (in 1986), the fruits of these labours appeared in the form of (firstly) the ARM second processor add-on (remember the Tube I mentioned above: well this hung off it. Think of it as a mixed 6502/ARM environment: the 6502 acted as a host controller for the second processor board) and this was followed by the Acorn Archimedes - a 32-bit RISC machine which was by some distance the fastest thing around at its pricepoint (Intel had the 386 and Motorola had the 68030). At this point in time, ARM stood for Acorn RISC Machine.
Fast forward a few years and it's turned out that trying to compete in the market place with a proprietary computer is not a winner: Acorn are haemhorraging cash on their computer line. They diversify into STBs and the like but they're not big enough to play outside of their own niche (they pretty much owned the education market in the UK) and beautiful hardware coupled with a fairly sweet OS (compare RISC OS 2 with Windows 286 and there can be only one winner) can't compete with the ability to run Word and Excel. However, they're raking in plenty of cash by licensing their (dirt-cheap, high-speed, low-power) RISC core to people who aren't worried about running Word or Excel but do need to go for four days on a single AA battery - mobile phones being a prime example. So, they spin off the ARM part (which has, by now become a joint venture with Apple, who are using the ARM in IIRC the Newton, and VLSI, who were fabbing the processor for Acorn and Apple) into a separate company called Advanced RISC Machines. The aim of this company is to develop and licence the ARM architecture to the world, which they do with significant success (ARM cores have been shipped in somewhere upwards of 400 million chips, and ARM made a profit, after tax, of some £30 million last year).
The ARM was (and still is) a lovely architecture to work with: it's incredibly small, runs off pretty much no power whatsoever and has a pretty modular architecture (you can licence various bits of the core as you require). They've also done some very cool things with it: Amulet is a asynchronous version of the ARM core which is being developed at Manchester University (the group's lead by Steve Fuurber, who was one of the original ARM designers).
Digital came into the picture because they licensed the ARM technology to produce the StrongARM: when Compaq bought Digital, they decided they didn't want to be in the silicon business so they transferred the StrongARM technologies/IP to Intel.
Does this make evrything clear? -- Cheers
Test it, create an OU, and make a user called "bsmith". Now create another OU anywhere else and try and create a user named "bsmith".
Were the two OUs in the same domain? Because what you're probably seeing is the SAM account names or user prinipal names clashing: these have to be unique on a per-domain basis to support downlevel clients doing NT authentication (not to mention that it's at least a defacto standard for UPN and primary mail address to be the same).
Then, given the accuracy of the rest of your post (No attribute-level replication? What are you smoking?), to expect you to get this bit right either is probably asking a bit much... -- Cheers
Both India and China already have growing middle classes with money to spend: take a look at rental prices in central Mumbai - they're as bad as central London. IIRC Shanghai's about as bad and let's not even mention HK -- Cheers
Be able to migrate IIS to Apache first, and still be able to access the MSSQL databases (FreeTDS?)
Use a scripting syntax similar to ASP so that the programmers don't have much of a headache learning new stuff (PHP looks like a solution).
Migrate MSSQL 7 to MySQL, PostgreSQL or other (Which one is better for web development?)
Wouldn't it be simplest to run the ASPs you've got (if they contain large amounts of business logic) under Chili!Soft's ASP doodad: you'd have to fsck about with all the database access side of it and if you're based round a three-tier architecture with middle tier COM components then you're SOL anyway, but it'd at least make porting the front-end fast.
As far as the backend goes, if you're going to port away from Microsoft SQL Server and your DBA doesn't bury an axe in your head at the suggestion, move to Sybase. From another comment in this thread:
You might also find that MySQL can do a lot of the MS SQL server stuff as long as your not using Triggers/Views/Stored Procedures etc
Moving to Sybase will cause you lots of pain, but it'll cause you far less pain than moving to anything else. You have been warned:-)
Don't you think that it might be better to roll out new systems on an experimental platform rather than trying to backport systems you've already got running? -- Cheers
I hate to break it to you, but you're doomed from the get-go: trying to catalogue every piece of hardware ever built and every computer language ever to get a grammar are impossible tasks (or at least the difficulty tends to infinity as t increases). After all, every self-respecting hacker has created at least one toy language to solve problems in a particular domain, and I'd guess that most hackers who've got enough motor co-ordination to avoid burning themselves on a soldering iron have built at least one piece of hardware. Are you going to catalogue all these?
For the record, I've created (that I can remember) three languages and breadboarded several bits of kit. The bits of hardware may be around somewhere, but I'm not sure where. -- Cheers
Because stopping and restarting, say, the local security authority sub-system is equivalent to rebooting an NT box: pretty much everything else that runs runs because the LSA allows it to. No LSA means no access to kernel objects whatsoever, which'd tend to result in things ending up in a heap pretty quickly. -- Cheers
Well, I don't know about your wallet, but I would find it really hard to replace it with a cell phone. How would you do this? I am curious.
Easily: mobile phone networks (unlike, say, the Visa network) are set up for micropayments. Want a can of Coke? Ring the number on the Coke machine and get 40 pence changed to your account. Want a newspaper and a packet of cigarettes? Take it to the till, let them ring it up and chage it to your phone. Try paying a 40p bill with a Visa card...
-- Cheers
Amusingly enough, that won't work (hint: read A Moron's Guide To COM: this may help explain how the Program Files\Plus!\Microsoft Internet directory has approximately 2/3 MB of code in it) -- Cheers
Moral of the story: pay the extra dollars/pounds/[insert unit of currency here] and hire someone who can find his or her arse with both hands rather than some slack-jawed student who reckons Linux is a real OS and mySQL is a real database. -- Cheers
Read up about Project Chrome, Microsoft's (ditched) followup to DirectX, and see WildTangent's web site for examples in action: it's dependent on IE4 or better and DirectX, so Nutscrape users, Mac users and those individuals running IE on Solaris or HP-UX are out, but it's certainly an interesting idea. There's more on it in Renegades Of Empire (haven't got the ISBN here, I'm sure you'll find it at your bookstore of choice). -- Cheers
UNIX and UNIX-like Operating Systems were not created to serve as desktop Operating Systems
Bollocks, pure and simple. The first Real-World deployment of Unix (i.e. outside ken's lab) was to the secretaries in the patent department of AT & T to enable them to write up patent applications, hence the emphasis on text-management and typesetting software in the early releases of the Unix system.
As for Unix being intended as a server OS - quick reality check required. Unix dates from the late 60s/early 70s. The client-server separation was fifteen years in the future - back then there were no clients. Unix was designed to support multiple terminals (tty0 - n) hanging off a central computer (originally a PDP8 IIRC) which displayed plain text in black and white: termcap files, full-screen editors and the like didn't arrive on the scene until the mid-70s and prior to that people edited with ed.
Get yourself a copy of the Unix Programming Environment and read it, then come back and post an informed comment. -- Cheers
Flash (by which I take it you mean the.SWF file format rather than the authoring tool) isn't necessarily 'big and clunky': the original format (packed bitfields within objects, objects byte-aligned within the file) is, in many ways, pretty well thought out: it's a nice balance between compactness of representation and speed of rendering, although its use of quadratic Beziers makes it a bit of a pig to draw circles, arcs etc and its text handling, by being user-agent-neutral, requires the programmer to jump through hoops, and it's got several advantages: most importantly it's an open format, it's widely supported and it's broadly standardised. It may not have the imprimatur of the W3C, but it's useful.
What tends to make it big and clunky is the habit designers have of embedding bitmap images into the.SWF either intentionally or unknowingly: the worst offender in this regard is Adobe's 'Flash-killer', LiveMotion which does some really evil things to generate.SWFs - from what I've been able to extract from LiveMotion-generated.SWFs, it seems to flatten all the layers it uses internally into a single bitmap and then stick it into the.SWF as is which is, unsuprisingly, somewhat inefficient.
-- Cheers
It's still there: Win-R, command.com and it's c:\ time. As to whether your legacy app will run: if it's reasonably polite and doesn't (for example) do raw hardware access then it probably will. If it's no more than a quivering mound of unstable hacks then you're probably SOL (if it runs under NT then it'll probably also run under Me) -- Cheers
Microsoft had a product called Commercial Internet Mail Server. Nobody bought it, it was blotted out of MS Official History, and one of the few references I can find to it on their site is the notice that support is being cancelled.
Correction: Normandy (the product which became the Commercial Internet System) was announced in June '96 as a set of addons to IIS 2.0 or 3.0 (IIRC). One of the early purchasers was Compuserve, who were (ironically) using it to help their migration from proprietary to open internetworking standards. By release 2.0, it had been renamed as Site Server: some of the Normandy stuff (such as the mail server) moved into the Option Pack.
This process has continued: there isn't going to be a Site Server 2000 'cos all the functionality is either provided natively, moved under the aegis of other parts of BackOffice or has thankfully been deprecated (Active Channel multicasting, anyone?) -- Cheers
I've heard several stories about Microsoft crashing when serving more than 30 clients on a Microsoft Access 97 database
Now, what I was discussing was TB-sized SQL Server databases (both MS and Sybase, BTW). In this context Access was a red herring. And FYI, I've had 400 - 500 users backended onto a MS SQL Server database from all across Europe (Smalltalk client, SQL Server 6.5, NT 4 Server) connecting over everything from 64KB frame relay upwards. The problems we had were exclusively with the (extremely badly-written) clients: the servers were stable.
Like I said in my previous post, go away and find out about what you're talking about. I'm posting from experience of running big SQL Server installations, you're posting your (unfounded) opinions. You've worked with big databases, you say: well, so've I (mail me privately for the full list if you're interested) and since you're so DBaware, you'll also be perfectly aware that what's true of one big database isn't true of another.
I've had 1.8 TB of data in a DSS database on MS SQL Server: this was indexed up the wazoo and loaded in batch from the sister OLTP system every night (and the load process was deeply fun...). The devices all lived away out on the (rather big) SAN and the backup hardware was a sight to behold...
Obviously my experience is no match for your opinion <g> - oh, and the day Oracle open their source is the day I see pigs flying. C'mon, this is Larry Ellison we're talking about. -- Cheers
Slashdot Mirror
Erm... set_intersection does precisely this, and in one line too...
Intel bought the StongARM stuff from DEC / Compaq
No they didn't, they licenced the design from ARM plc, as did DEC/Compaq
Yes it IS an ARM processor, but not an INTEL one. It is made by a British Company CALLED ARM. You can find them at: www.arm.com They compete with INTEL in the same space with this CPU.
Sorry, wrong again. ARM don't make anything tangible: they're an IP company pure and simple. They license their chip designs to anyone who's prepared to pay the licensing costs. At the moment, this is pretty much every hardware/white-goods company out there.
A little bit of history: ARM is a spin-off of the late and lamented Acorn Computers. In the early to mid-80's, Acorn (who had a very nice range of 6502 based micros - the Tube, a shared-nothing multiprocessing architecture, was a very groovy thing to have in a £400 micro) realised that these processors weren't going anywhere and the alternatives didn't fit their idea of what a quality CPU should do (this was in the days when RISC was the next big thing but the only commercially available RISC processors cost the earth...), so they decided to design their own RISC architecture and develop a processor and chipset.
Some years later (in 1986), the fruits of these labours appeared in the form of (firstly) the ARM second processor add-on (remember the Tube I mentioned above: well this hung off it. Think of it as a mixed 6502/ARM environment: the 6502 acted as a host controller for the second processor board) and this was followed by the Acorn Archimedes - a 32-bit RISC machine which was by some distance the fastest thing around at its pricepoint (Intel had the 386 and Motorola had the 68030). At this point in time, ARM stood for Acorn RISC Machine.
Fast forward a few years and it's turned out that trying to compete in the market place with a proprietary computer is not a winner: Acorn are haemhorraging cash on their computer line. They diversify into STBs and the like but they're not big enough to play outside of their own niche (they pretty much owned the education market in the UK) and beautiful hardware coupled with a fairly sweet OS (compare RISC OS 2 with Windows 286 and there can be only one winner) can't compete with the ability to run Word and Excel. However, they're raking in plenty of cash by licensing their (dirt-cheap, high-speed, low-power) RISC core to people who aren't worried about running Word or Excel but do need to go for four days on a single AA battery - mobile phones being a prime example. So, they spin off the ARM part (which has, by now become a joint venture with Apple, who are using the ARM in IIRC the Newton, and VLSI, who were fabbing the processor for Acorn and Apple) into a separate company called Advanced RISC Machines. The aim of this company is to develop and licence the ARM architecture to the world, which they do with significant success (ARM cores have been shipped in somewhere upwards of 400 million chips, and ARM made a profit, after tax, of some £30 million last year). The ARM was (and still is) a lovely architecture to work with: it's incredibly small, runs off pretty much no power whatsoever and has a pretty modular architecture (you can licence various bits of the core as you require). They've also done some very cool things with it: Amulet is a asynchronous version of the ARM core which is being developed at Manchester University (the group's lead by Steve Fuurber, who was one of the original ARM designers).
Digital came into the picture because they licensed the ARM technology to produce the StrongARM: when Compaq bought Digital, they decided they didn't want to be in the silicon business so they transferred the StrongARM technologies/IP to Intel. Does this make evrything clear?
--
Cheers
Were the two OUs in the same domain? Because what you're probably seeing is the SAM account names or user prinipal names clashing: these have to be unique on a per-domain basis to support downlevel clients doing NT authentication (not to mention that it's at least a defacto standard for UPN and primary mail address to be the same).
Then, given the accuracy of the rest of your post (No attribute-level replication? What are you smoking?), to expect you to get this bit right either is probably asking a bit much...
--
Cheers
The Yamaha SW1000XG/DSP Factory combo is superb (but pricey).
--
Cheers
Both India and China already have growing middle classes with money to spend: take a look at rental prices in central Mumbai - they're as bad as central London. IIRC Shanghai's about as bad and let's not even mention HK
--
Cheers
I was there, and it wasn't pretty. IIOP was a good thing but it came far too late.
--
Cheers
Erm... isn't this the whole point of COM+? Or have I missed your point entirely?
--
Cheers
- Be able to migrate IIS to Apache first, and still be able to access the MSSQL databases (FreeTDS?)
Wouldn't it be simplest to run the ASPs you've got (if they contain large amounts of business logic) under Chili!Soft's ASP doodad: you'd have to fsck about with all the database access side of it and if you're based round a three-tier architecture with middle tier COM components then you're SOL anyway, but it'd at least make porting the front-end fast.Use a scripting syntax similar to ASP so that the programmers don't have much of a headache learning new stuff (PHP looks like a solution).
Migrate MSSQL 7 to MySQL, PostgreSQL or other (Which one is better for web development?)
As far as the backend goes, if you're going to port away from Microsoft SQL Server and your DBA doesn't bury an axe in your head at the suggestion, move to Sybase. From another comment in this thread:
Moving to Sybase will cause you lots of pain, but it'll cause you far less pain than moving to anything else. You have been warned:-)
Don't you think that it might be better to roll out new systems on an experimental platform rather than trying to backport systems you've already got running?
--
Cheers
For the record, I've created (that I can remember) three languages and breadboarded several bits of kit. The bits of hardware may be around somewhere, but I'm not sure where.
--
Cheers
Because stopping and restarting, say, the local security authority sub-system is equivalent to rebooting an NT box: pretty much everything else that runs runs because the LSA allows it to. No LSA means no access to kernel objects whatsoever, which'd tend to result in things ending up in a heap pretty quickly.
--
Cheers
And then help demonstrate to the world that most Merkins can't handle English either.
--
Cheers
Well, I don't know about your wallet, but I would find it really hard to replace it with a cell phone. How would you do this? I am curious.
Easily: mobile phone networks (unlike, say, the Visa network) are set up for micropayments. Want a can of Coke? Ring the number on the Coke machine and get 40 pence changed to your account. Want a newspaper and a packet of cigarettes? Take it to the till, let them ring it up and chage it to your phone. Try paying a 40p bill with a Visa card...
--
Cheers
Amusingly enough, that won't work (hint: read A Moron's Guide To COM: this may help explain how the Program Files\Plus!\Microsoft Internet directory has approximately 2/3 MB of code in it)
--
Cheers
sp_OACreate
sp_OAMethod
sp_OADestroy
sp_OASetProperty
sp_OAGetErrorInfo
sp_OAStop
sp_OAGetProperty
Moral of the story: pay the extra dollars/pounds/[insert unit of currency here] and hire someone who can find his or her arse with both hands rather than some slack-jawed student who reckons Linux is a real OS and mySQL is a real database.
--
Cheers
Guess what: the people you're working with (and possibly you yourself, if you also knew there was no security in your systems) are morons.
--
Cheers
In that case, take a long cold look at your video drivers...
--
Cheers
Read up about Project Chrome, Microsoft's (ditched) followup to DirectX, and see WildTangent's web site for examples in action: it's dependent on IE4 or better and DirectX, so Nutscrape users, Mac users and those individuals running IE on Solaris or HP-UX are out, but it's certainly an interesting idea. There's more on it in Renegades Of Empire (haven't got the ISBN here, I'm sure you'll find it at your bookstore of choice).
--
Cheers
Bollocks, pure and simple. The first Real-World deployment of Unix (i.e. outside ken's lab) was to the secretaries in the patent department of AT & T to enable them to write up patent applications, hence the emphasis on text-management and typesetting software in the early releases of the Unix system.
As for Unix being intended as a server OS - quick reality check required. Unix dates from the late 60s/early 70s. The client-server separation was fifteen years in the future - back then there were no clients. Unix was designed to support multiple terminals (tty0 - n) hanging off a central computer (originally a PDP8 IIRC) which displayed plain text in black and white: termcap files, full-screen editors and the like didn't arrive on the scene until the mid-70s and prior to that people edited with ed.
Get yourself a copy of the Unix Programming Environment and read it, then come back and post an informed comment.
--
Cheers
What tends to make it big and clunky is the habit designers have of embedding bitmap images into the .SWF either intentionally or unknowingly: the worst offender in this regard is Adobe's 'Flash-killer', LiveMotion which does some really evil things to generate .SWFs - from what I've been able to extract from LiveMotion-generated .SWFs, it seems to flatten all the layers it uses internally into a single bitmap and then stick it into the .SWF as is which is, unsuprisingly, somewhat inefficient.
--
Cheers
S is required.
Isn't the one at the end of jumps enough, or does it take two 'S's to rock your world?
--
Cheers
It's still there: Win-R, command.com and it's c:\ time. As to whether your legacy app will run: if it's reasonably polite and doesn't (for example) do raw hardware access then it probably will. If it's no more than a quivering mound of unstable hacks then you're probably SOL (if it runs under NT then it'll probably also run under Me)
--
Cheers
Correction: Normandy (the product which became the Commercial Internet System) was announced in June '96 as a set of addons to IIS 2.0 or 3.0 (IIRC). One of the early purchasers was Compuserve, who were (ironically) using it to help their migration from proprietary to open internetworking standards. By release 2.0, it had been renamed as Site Server: some of the Normandy stuff (such as the mail server) moved into the Option Pack.
This process has continued: there isn't going to be a Site Server 2000 'cos all the functionality is either provided natively, moved under the aegis of other parts of BackOffice or has thankfully been deprecated (Active Channel multicasting, anyone?)
--
Cheers
I've heard several stories about Microsoft crashing when serving more than 30 clients on a Microsoft Access 97 database
Now, what I was discussing was TB-sized SQL Server databases (both MS and Sybase, BTW). In this context Access was a red herring. And FYI, I've had 400 - 500 users backended onto a MS SQL Server database from all across Europe (Smalltalk client, SQL Server 6.5, NT 4 Server) connecting over everything from 64KB frame relay upwards. The problems we had were exclusively with the (extremely badly-written) clients: the servers were stable.
Like I said in my previous post, go away and find out about what you're talking about. I'm posting from experience of running big SQL Server installations, you're posting your (unfounded) opinions. You've worked with big databases, you say: well, so've I (mail me privately for the full list if you're interested) and since you're so DBaware, you'll also be perfectly aware that what's true of one big database isn't true of another.
Oh, and try and relax a bit.
--
Cheers
I've had 1.8 TB of data in a DSS database on MS SQL Server: this was indexed up the wazoo and loaded in batch from the sister OLTP system every night (and the load process was deeply fun...). The devices all lived away out on the (rather big) SAN and the backup hardware was a sight to behold...
Obviously my experience is no match for your opinion <g> - oh, and the day Oracle open their source is the day I see pigs flying. C'mon, this is Larry Ellison we're talking about.
--
Cheers