I don't see why. Most student level electronics simulation just shouldn't be all that CPU intensive. When I was an EE student 10 years ago, people did just fine with 150MHz machines running SPICE.
I dunno, maybe I'm just not particularly good at using SPICE, but I've run simulations of very simple circuits that took 10-20 hours on GHz+ machines. Maybe there are workarounds (although I looked for a while and didn't find any) but it seems there are some circuits that SPICE is very poor at handling (the circuit I was designing was a high-power, high-frequency pulse width modulator, and one of the things it really struggles with is high speed switching) -- I'd guess once upon a time student courses would avoid such circuits because of the difficulty in simulating them, but nowadays it might not be so obvious.
Demo versions of software are just that - meant so you can test out the software to see if it fits your needs. If you're going to be using this software year after year to teach a course at university, you should get a licence, one per user.
You've clearly never seen how expensive OrCAD is. If the T&Cs allow him to use the demo for his purpose, he should be using the demo. If not, and if he has a significant number of users, he could easily be running into budget limitations for his department. The prices aren't on the OrCAD web site, but when I requested a quotation for a single copy, IIRC the components I would have needed for my project came to well over USD 5,000. I decided a cheaper option would do the job, even if I did have to spend a little time working around limitations in the software.
Even if the lack-of-network-connection weren't an issue, running SPICE simulations is _extremely_ processor intensive. My guess is the students will be running jobs that take 100% CPU for 4-5 hours at a time if they're doing anything non-trivial. Not exactly the kind of load you want to stick on your terminal server system unless you're geared up for it...
As for the rules behind the legal characters in a host name I will follow your lead and quote RFC1035:
> The labels must follow the rules for ARPANET host names. They must > start with a letter, end with a letter or digit, and have as interior > characters only letters, digits, and hyphen. There are also some > restrictions on the length. Labels must be 63 characters or less.
You're quoting that section out of context. Let me quote some earlier paragraphs:
2.3.1. Preferred name syntax
The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes.
However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs....
The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET).
I.e., what you're quoting is a recommendation for what names people should assign to nodes in order to reduce interoperability problems, and not a strict requirement.
For reference, you should probably read this blog post. The executive summary: the lead developers of WoW have recently switched teams to work on Blizzard's next big title, leaving only some fairly inexperienced devs behind. They're making what amounts to newbie mistakes because they've never been in charge of balancing a live game before. An experience project lead would probably not have done this. I'm assuming JGE has somebody experienced at the helm, so issues like the one you bring up are unlikely to be a major problem for them.
I've requested several SSL certificates over the years. Never ever have I received such an email to confirm ownership, nor was I pre-confirmed as the domains were registered elsewhere. Okay, so the CA was not netsol or thawte. But it sure was a CA that was acknowledged by both MSIE6/MSIE7/MSIE8/FF2/FF3
Which CA do you use? Every one I've ever used has performed domain control validation, and it's supposed to be a standard step in processing a request for a cert.
You could argue that but I might argue that NULL in not a valid character in an FQDN. It is by extension not a valid character in the CN attribute of a certificate issued for an FQDN
Isn't it? RFC1034 (STD13; Domain concepts and facilities) states:
Each node has a label, which is zero to 63 octets in length. Brother nodes may not have the same label, although the same label can be used for nodes which are not brothers. One label is reserved, and that is the null (i.e., zero length) label used for the root.
Internally, programs that manipulate domain names should represent them as sequences of labels, where each label is a length octet followed by an octet string.
Note two things: first, no mention of any restrictions on valid characters are made here, secondly any program that fails to compare beyond a null character in a domain name is almost certainly neglecting this suggestion of the RFC. The RFC continues:
As a matter of policy, the DNS technical specifications do not mandate a particular tree structure or rules for selecting labels; its goal is to be as general as possible, so that it can be used to build arbitrary applications.
RFC1035 (aka STD13; Domain names, implementation and specification) states:
Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions. Name servers and resolvers must compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII with zero parity. Non-alphabetic codes must match exactly.
This seems to suggest a "label" (i.e. a component of a domain name) may contain _any_ 8 bit characters. It _recommends_ avoiding some unusual characters, but this is explicitly not a requirement. RFC 2185 updates RFC1035 and states:
Those restrictions [related to length of labels]
aside, any binary string whatever can be used as the label of any
resource record. Similarly, any binary string can serve as the value
of any record that includes a domain name as some or all of its value
(SOA, NS, MX, PTR, CNAME, and any others that may be added).
Implementations of the DNS protocols must not place any restrictions
on the labels that can be used.
So "any binary string whatever" is valid in a domain name, according to the RFCs. This would include one with an embedded null.
So it doesn't seem to me that the CAs have actually done anything wrong here. NULL _is_ a valid character in a FQDN.
No, all we have to do is make CA's liable for the certs the issue
Technically, these certs are correct. The domain name in them is for a server held by the applicant. The browser is misinterpreting that domain name. I fail to see how the CA could be held liable, even if there were any basis to do so under any circumstance.
Isn't that why they charge huge amounts for the certs?
No, I think that's called rampant profiteering. And because competition has driven the price down too low for them (oh no, they can only get away with charging ~50 euros for an automatically-generated chunk of data) they've introduced extended validation certs, where they actually do what they were supposed to be doing in the first place and charge yet more money for it...
The CA issued a malformed Cert. The browser (firefox) did not catch the malformation. Who is to blame? Both I would think.
Which the article is quite clear about. It's also clear that although both are to blame, only the browser can fix this for any certs that may already be in the wild...
Fixed that for you. The USA's policies these days are driven primary by blind, largely irrational fear.
Of course they are. We all know that the USA is pretty far out on the right wing spectrum when compared to most other democratic countries. And we also know that conservatives are more fearful than liberals. Draw you own conclusions.
I remember a sort of userland breaking point: I tried to drag and drop a jpg in a browser window (Firefox) to some photo editor. It didn't work. Macs and Windows have been able to do this since at least the mid-90s.
I just tried dragging from Firefox to Photoshop 5 (released 1998) on Windows XP and it didn't work. It accepts drags of files, but not images from a browser window. And the OS is irrelevant to this, anyway: all the relevant OSs provide a datatype-independent method of dragging and dropping from one application to another. If two applications don't support the same datatypes (and it seems Firefox [which provides only URLs, I believe] and Photoshop [which seems to accept only files] don't) then they can't communicate.
But isn't that precisely what object orientation was invented to solve? To find a way of unifying data transfer between absolutely everything, everywhere, by sending not raw data but objects which could then be queried to ask things like 'what kind of thing are you?' and 'give me your data in Format X, Y or Z which I can read'.
Object orientation does solve this, but only for systems that can share objects with each other. The problem is that, typically at least, objects are represented as a data structure in memory that has, among other things, pointers to code to execute in response to different messages. To execute a method, we find the correct pointer, call that code and pass it a pointer to the object whose method it is. This is by far the most efficient way of implementing objects, so it is almost universally used.
The downside to this implementation is that objects depend on a specific memory map, i.e. they are process specific. You can't just rip an object out of one process and send it to another, you have to serialize it and deserialize it along the way, and the receiving process has to know about that object's class because it has to have access to its methods' code as well the object's data. There are three general solutions to moving objects from one application to another:
Run all applications in the same address space/virtual machine. This is the approach that Smalltalk took, and is also done today in some research systems (Microsoft's Singularity springs to mind, but there are others too... and I think Singularity prevents objects being transferred between running processes for its own subtly different reasons, IRRC). It isn't done in mainstream operating systems because there are a few serious downsides:
All applications must be written in languages that are compatible with each other's object representation. In most cases where systems like this have been implemented, there is only a single language available.
In order to meet the process isolation requirements that we have of modern operating systems (i.e. a failure in one application doesn't cause the entire system to fail) the language _must_ be both type safe and memory safe (i.e. memory used by an object of one type cannot be reused by an object of another type while there is a live pointer to that memory in the system). Memory safe languages almost always do not offer explicit memory management, as the two features are extremely difficult to combine. Some operations are less efficient in type safe environments. Consequently, such environments usually offer poor responsiveness and are not suitable for realtime uses. People avoid such environments.
If you don't have a type safe environment, or your type system does not offer protection of private elements and a means to prevent subclassing, it is impossible to implement a secure system. Any running application can interfere with any other running application at will. Smalltalk suffers from this problem: any code running on a smalltalk system can perform any operation it is possible to perform on the system. Smalltalk cannot provide isolation of multiple security domains.
Provide a remote method invocation framework. Objects are held in a server process that receives messages from client processes and invokes operations on the object in response to them. Such systems are generally cumbersome to work with, requiring a lot of developer overhead in most cases. COM, which Windows' drag & drop is based on, uses this approach.
Serialize the object, deserialize it in the recipient, and provide a copy of the object's methods in a form which can be linked on demand into the recipient. Windows implements this in the form of OLE, an extension of COM, which some drag and drop applications support (e.g. MS Office). The problem with this is that the requirements are extremely complicated so few developers bother registering their objects as OLE-capable. It just isn't worth the effort.
Why on earth is BIND shipping with assertions that cause the entire server to exit when they fail? They should just cause processing of the current request to exit.
Yeah seriously; he should just start a band and try promoting himself under his own name. Call it the Steve Mill... umm, never mind.
Some people call him the space cowboy. Some call him the gangster of love. Some people like to call him Maurice. 'Cause he speaks bullshit of moronic ignorance.
They've locked on to "Agile" programming and SCRUM project management as methods for driving this granularity into the development and test processes. They want tasks broken down to 15 minute increments and balk when any task takes more than a couple of hours to complete. All this so that they can achieve "visibility" and "predictability" for a given project, i.e. they get more status reports with pretty charts and graphs. I really despise the term "burn down" which springs from the whole thing as well.
This is bizarre, as it's basically the antithesis of what Agile and Scrum are actually supposed to be about. The way Scrum and other Agile management techniques are supposed to work is this:
* The customer creates tasks ("stories") that are typically reasonably large chunks of work * The developers estimate them, usually in either days or half days (or, if you're in an XP shop, opaque "points" that are meaningless other than to relate the size of a task to the sizes of other tasks you've also estimated recently) and points out any dependencies * The customer decides what order they should be completed in
Burn-down charts are used at the level of stories and provide a projection of time to completion of all stories that have been estimated (usually about 2-4 weeks worth).
I suppose that's what makes it all the more irritating when managers think they have yet-another-silver-bullet for project management that they misuse causing more Maker frustration and possibly increasing the chance for failure rather than ameliorating it.
If your company is treating Agile as a silver bullet handed down from on high to solve all of their problems, You're Doing It Wrong (TM). The basic point of Agile is to let the team assess what's helpful and what isn't, and to discard the stuff that isn't. If you're estimating tasks on too small a timescale, and spending too much time producing statistics rather than actual code, the Agile way is for the team to raise this in the next retrospective (which should be one of the few meetings you have, the other obvious one being the daily stand-up meeting... which you do stand for, right?) and for the team to change the way they work. Agile teams vary their processes to work more effectively, and if your management has a problem with that, you aren't an Agile team.
That's really strange. I can only assume the problem comes from unskilled management unused to dealing with skilled workers completing a complex task.
You mean there's another kind?
I work in industrial engineering, and all my labour estimates are set within a half-day's time, and that wisdom came from the management types around me who stopped me when I was scheduling things to take an hour or two.
Well, there's a difference between scheduling how long a job is going to take and scheduling your work day on an individual level. I tend to work in half-days too, but I still have the problem described in the article that my days get broken up by meetings scheduled in the middle of them, or by my manager expecting me to switch tasks on a regular basis.
I think there's a reason this works for you and not for programmers. I can only assume that as an industrial engineer your work environment is somewhat different from a programmers: specifically, I'd guess you work in a workshop-type environment. Your managers work in an office that's attached to the workshop. (I say this because when I've worked with engineering companies before this has been how they've set the place up.) Because there's a clear divide between where you work and where your manager works, it emphasizes to the manager that the work you do is different.
Here in the programming world, the divide is a lot less clear. For instance, where I work, we all have an open plan office. My manager sits on the desk to my right. He can interrupt me without getting out of his chair or even lifting his phone handset. Because what I do and what he does look similar (i.e, we both sit in front of a computer and type) he assumes that it _is_ similar, and that what works for him is likely to work for me.
This suggests a possible organizational solution to the problem, at least for larger shops: separate managers and development teams into different environments. Make them as different as you can and put some kind of barrier between the two.
Pretend you're Kirk, and you're filling in the "Captain's Log".
Nice. I'm gonna use stardates on my next timesheet. Stardate -314569.35 to -314569.52 -- writing scripts to import price list from excel onto the database.
Much more likely that this screen will be required for all installs, including the final setup that OEM version do when you turn them on for the first time...
That's called the Out-Of-Box Experience.
Just thought I'd let everyone chuckle at the silly name.
Agreed. I'm normally a cheap-assed bastard who will go so far out of his way to avoid paying for stuff you wouldn't believe it, but I've shelled out cash for items in utransaction mmos before. The model does work.
Slashdot Mirror
I don't see why. Most student level electronics simulation just shouldn't be all that CPU intensive. When I was an EE student 10 years ago, people did just fine with 150MHz machines running SPICE.
I dunno, maybe I'm just not particularly good at using SPICE, but I've run simulations of very simple circuits that took 10-20 hours on GHz+ machines. Maybe there are workarounds (although I looked for a while and didn't find any) but it seems there are some circuits that SPICE is very poor at handling (the circuit I was designing was a high-power, high-frequency pulse width modulator, and one of the things it really struggles with is high speed switching) -- I'd guess once upon a time student courses would avoid such circuits because of the difficulty in simulating them, but nowadays it might not be so obvious.
OK, I'm gonna bite as no-one else has so far...
Demo versions of software are just that - meant so you can test out the software to see if it fits your needs. If you're going to be using this software year after year to teach a course at university, you should get a licence, one per user.
You've clearly never seen how expensive OrCAD is. If the T&Cs allow him to use the demo for his purpose, he should be using the demo. If not, and if he has a significant number of users, he could easily be running into budget limitations for his department. The prices aren't on the OrCAD web site, but when I requested a quotation for a single copy, IIRC the components I would have needed for my project came to well over USD 5,000. I decided a cheaper option would do the job, even if I did have to spend a little time working around limitations in the software.
Even if the lack-of-network-connection weren't an issue, running SPICE simulations is _extremely_ processor intensive. My guess is the students will be running jobs that take 100% CPU for 4-5 hours at a time if they're doing anything non-trivial. Not exactly the kind of load you want to stick on your terminal server system unless you're geared up for it...
You're quoting that section out of context. Let me quote some earlier paragraphs:
I.e., what you're quoting is a recommendation for what names people should assign to nodes in order to reduce interoperability problems, and not a strict requirement.
have fun trying to register a real domain name with a : / or " in it. It simply cannot be done.
there is a protocol layer and there are limitations placed by ICANN on your TLD.
Yes, but you can put whatever you want in your subdomains, which is what this attack was based on, without having to follow ICANN's rules.
I prefer not to say, criminals are reading /. as well.
I strongly suspect the criminals already know. The rest of us can remove the CA from our list.
For reference, you should probably read this blog post. The executive summary: the lead developers of WoW have recently switched teams to work on Blizzard's next big title, leaving only some fairly inexperienced devs behind. They're making what amounts to newbie mistakes because they've never been in charge of balancing a live game before. An experience project lead would probably not have done this. I'm assuming JGE has somebody experienced at the helm, so issues like the one you bring up are unlikely to be a major problem for them.
No certificate should have been issued for an invalid domain name (NUL characters are not permitted in DNS identifiers).
Yes they are. Please see my previous comment on this subject.
CAs should be fixed to not allow garbage in the domain. \0 isn't a legal character in DNS protocol [...]
Yes, it is. See my previous comment on this topic.
I've requested several SSL certificates over the years. Never ever have I received such an email to confirm ownership, nor was I pre-confirmed as the domains were registered elsewhere. Okay, so the CA was not netsol or thawte. But it sure was a CA that was acknowledged by both MSIE6/MSIE7/MSIE8/FF2/FF3
Which CA do you use? Every one I've ever used has performed domain control validation, and it's supposed to be a standard step in processing a request for a cert.
You could argue that but I might argue that NULL in not a valid character in an FQDN. It is by extension not a valid character in the CN attribute of a certificate issued for an FQDN
Isn't it? RFC1034 (STD13; Domain concepts and facilities) states:
Note two things: first, no mention of any restrictions on valid characters are made here, secondly any program that fails to compare beyond a null character in a domain name is almost certainly neglecting this suggestion of the RFC. The RFC continues:
RFC1035 (aka STD13; Domain names, implementation and specification) states:
This seems to suggest a "label" (i.e. a component of a domain name) may contain _any_ 8 bit characters. It _recommends_ avoiding some unusual characters, but this is explicitly not a requirement. RFC 2185 updates RFC1035 and states:
So "any binary string whatever" is valid in a domain name, according to the RFCs. This would include one with an embedded null.
So it doesn't seem to me that the CAs have actually done anything wrong here. NULL _is_ a valid character in a FQDN.
No, all we have to do is make CA's liable for the certs the issue
Technically, these certs are correct. The domain name in them is for a server held by the applicant. The browser is misinterpreting that domain name. I fail to see how the CA could be held liable, even if there were any basis to do so under any circumstance.
Isn't that why they charge huge amounts for the certs?
No, I think that's called rampant profiteering. And because competition has driven the price down too low for them (oh no, they can only get away with charging ~50 euros for an automatically-generated chunk of data) they've introduced extended validation certs, where they actually do what they were supposed to be doing in the first place and charge yet more money for it...
The CA issued a malformed Cert. The browser (firefox) did not catch the malformation. Who is to blame? Both I would think.
Which the article is quite clear about. It's also clear that although both are to blame, only the browser can fix this for any certs that may already be in the wild...
Fixed that for you. The USA's policies these days are driven primary by blind, largely irrational fear.
Of course they are. We all know that the USA is pretty far out on the right wing spectrum when compared to most other democratic countries. And we also know that conservatives are more fearful than liberals. Draw you own conclusions.
I remember a sort of userland breaking point: I tried to drag and drop a jpg in a browser window (Firefox) to some photo editor. It didn't work. Macs and Windows have been able to do this since at least the mid-90s.
I just tried dragging from Firefox to Photoshop 5 (released 1998) on Windows XP and it didn't work. It accepts drags of files, but not images from a browser window. And the OS is irrelevant to this, anyway: all the relevant OSs provide a datatype-independent method of dragging and dropping from one application to another. If two applications don't support the same datatypes (and it seems Firefox [which provides only URLs, I believe] and Photoshop [which seems to accept only files] don't) then they can't communicate.
But isn't that precisely what object orientation was invented to solve? To find a way of unifying data transfer between absolutely everything, everywhere, by sending not raw data but objects which could then be queried to ask things like 'what kind of thing are you?' and 'give me your data in Format X, Y or Z which I can read'.
Object orientation does solve this, but only for systems that can share objects with each other. The problem is that, typically at least, objects are represented as a data structure in memory that has, among other things, pointers to code to execute in response to different messages. To execute a method, we find the correct pointer, call that code and pass it a pointer to the object whose method it is. This is by far the most efficient way of implementing objects, so it is almost universally used.
The downside to this implementation is that objects depend on a specific memory map, i.e. they are process specific. You can't just rip an object out of one process and send it to another, you have to serialize it and deserialize it along the way, and the receiving process has to know about that object's class because it has to have access to its methods' code as well the object's data. There are three general solutions to moving objects from one application to another:
I'm not sur
Why on earth is BIND shipping with assertions that cause the entire server to exit when they fail? They should just cause processing of the current request to exit.
Yeah seriously; he should just start a band and try promoting himself under his own name. Call it the Steve Mill... umm, never mind.
Some people call him the space cowboy.
Some call him the gangster of love.
Some people like to call him Maurice.
'Cause he speaks bullshit of moronic ignorance.
They've locked on to "Agile" programming and SCRUM project management as methods for driving this granularity into the development and test processes. They want tasks broken down to 15 minute increments and balk when any task takes more than a couple of hours to complete. All this so that they can achieve "visibility" and "predictability" for a given project, i.e. they get more status reports with pretty charts and graphs. I really despise the term "burn down" which springs from the whole thing as well.
This is bizarre, as it's basically the antithesis of what Agile and Scrum are actually supposed to be about. The way Scrum and other Agile management techniques are supposed to work is this:
* The customer creates tasks ("stories") that are typically reasonably large chunks of work
* The developers estimate them, usually in either days or half days (or, if you're in an XP shop, opaque "points" that are meaningless other than to relate the size of a task to the sizes of other tasks you've also estimated recently) and points out any dependencies
* The customer decides what order they should be completed in
Burn-down charts are used at the level of stories and provide a projection of time to completion of all stories that have been estimated (usually about 2-4 weeks worth).
I suppose that's what makes it all the more irritating when managers think they have yet-another-silver-bullet for project management that they misuse causing more Maker frustration and possibly increasing the chance for failure rather than ameliorating it.
If your company is treating Agile as a silver bullet handed down from on high to solve all of their problems, You're Doing It Wrong (TM). The basic point of Agile is to let the team assess what's helpful and what isn't, and to discard the stuff that isn't. If you're estimating tasks on too small a timescale, and spending too much time producing statistics rather than actual code, the Agile way is for the team to raise this in the next retrospective (which should be one of the few meetings you have, the other obvious one being the daily stand-up meeting... which you do stand for, right?) and for the team to change the way they work. Agile teams vary their processes to work more effectively, and if your management has a problem with that, you aren't an Agile team.
That's really strange. I can only assume the problem comes from unskilled management unused to dealing with skilled workers completing a complex task.
You mean there's another kind?
I work in industrial engineering, and all my labour estimates are set within a half-day's time, and that wisdom came from the management types around me who stopped me when I was scheduling things to take an hour or two.
Well, there's a difference between scheduling how long a job is going to take and scheduling your work day on an individual level. I tend to work in half-days too, but I still have the problem described in the article that my days get broken up by meetings scheduled in the middle of them, or by my manager expecting me to switch tasks on a regular basis.
I think there's a reason this works for you and not for programmers. I can only assume that as an industrial engineer your work environment is somewhat different from a programmers: specifically, I'd guess you work in a workshop-type environment. Your managers work in an office that's attached to the workshop. (I say this because when I've worked with engineering companies before this has been how they've set the place up.) Because there's a clear divide between where you work and where your manager works, it emphasizes to the manager that the work you do is different.
Here in the programming world, the divide is a lot less clear. For instance, where I work, we all have an open plan office. My manager sits on the desk to my right. He can interrupt me without getting out of his chair or even lifting his phone handset. Because what I do and what he does look similar (i.e, we both sit in front of a computer and type) he assumes that it _is_ similar, and that what works for him is likely to work for me.
This suggests a possible organizational solution to the problem, at least for larger shops: separate managers and development teams into different environments. Make them as different as you can and put some kind of barrier between the two.
Pretend you're Kirk, and you're filling in the "Captain's Log".
Nice. I'm gonna use stardates on my next timesheet. Stardate -314569.35 to -314569.52 -- writing scripts to import price list from excel onto the database.
Much more likely that this screen will be required for all installs, including the final setup that OEM version do when you turn them on for the first time...
That's called the Out-Of-Box Experience.
Just thought I'd let everyone chuckle at the silly name.
Agreed. I'm normally a cheap-assed bastard who will go so far out of his way to avoid paying for stuff you wouldn't believe it, but I've shelled out cash for items in utransaction mmos before. The model does work.
Damned popular press covering science stories...
"All you need are somebody's skin cells to create a human baby.""
And, you know, an embryo. Which will become a human baby all by itself anyway.