Oh, a bit of digging says that they are almost entirely hydroelectric production, so this is an actual real reduction in fossil fuel dependance. Awesome!
I'm guessing their grid has a fair bit of gas based electricity generation, so although the headline is nice, i'm waiting for their fossil fuel dependence to really drop to show what is possible.
You mean 3.5mm right? 1/4 inch, 3.5mm stereo, those are the two standards, but I take your point, and i'm happy to use my 3.5mm jack headphones every day. Works for me!
I'd be careful about calling something a fake when it's been tested in court. I imagine the intention is to portray that this Italian company has taken advantage of some weakness in an existing companies trade mark registration, which very well may be the case. A quick look on the web suggests the Italian outfit started off selling the products of the US company, before starting it's own product lines.
Personally if I produced a product and the only thing that differentiated it from another product available on the market was my use of my trademark on the front of the product, i'd really wonder what I was doing. This is a very recent idea in clothing, say 20-30 years old or so. Before then, the trademark would indicate quality, which appears to no longer be the case.
Agreed. The simplest binary formats are very simple to store and retrieve, if you think about it, you just create a struct with non-pointer/reference types, and write your fields. Serialisation is a write of the memory to a file, deserialisation is a read. All in all, it'll be 10 lines of blindingly obvious code without any chance of programming errors, buffer overruns etc.
However, and this is a big however, it's completely inflexible, and has a number of massive downsides. It's going to be endian specific, it can't represent complex relationships between objects, it's not going to have any versioning support, the list goes on.
Once you start trying to address the above issues, you end up realising the problem is a bit larger than you thought, and end up re-creating something like google's Protocol Buffers, or Real Logic's Simple Binary Encoding, so you are better off using an established framework which then involves understanding how these work. At this point, you've kind of added back the complexity of the text based serialisation/deserialisation approach, so API wise it's not a great win. Performance wise though, something like SBE is leaps ahead of native serialisation if you don't need the flexibility that native serialisation supports (with it's polymorphism etc). Do check out SBE if you are wanting a lightish and performant mechanism, it's worked well for me (https://github.com/real-logic/simple-binary-encoding)
Seem to have gone a little away from the original point, apologies.
It's one of the only features I use on my feature phone. You could take out the cameras, GPS, motion sensors and probably half a dozen other bits i've never heard of let alone used, but the headphone socket is important to me.
If only I had an application that would be tractable on this sort of hardware. The ray tracing side of things is boring to me, i'd be interested to know how this works out for large matrix operations, or signal processing type applications. Still, more is more when it comes to compute!
The theoreticians don't come across as arrogant at all. To your point, the article specifically mentions that the emergent gravity theorists will need to work to resolve this issue, and that their work gives insights into other areas, and may be helpful for people doing other work (like quantum gravity). This in fact sounds deeply collaborative to me!
BTW, i'm not a theoretician, but i've spent a fair bit of time around various theoretical physicists, and the practical variety too, and they are to a person great to be around.
Agreed, the exact purpose is hazy. In europe we have the MiFID II requirements for trading systems and exchanges, and this is covered in RTS-25, which is here:
I believe earlier drafts had timing requirements to the nanosecond until it was pointed out that a reference point was needed. The intention is to be able to track the order of events, and to put a requirement on exchanges, brokers and market participants to be able to provide audit information showing the order of events in their system to demonstrate that they are acting appropriately (so for example, not reordering order flows from clients to give preferential treatment to one client, or to themselves). How successful this is or will be is open, but the concept is a good one.
The article is pretty ambiguous - I originally read their claim that they ' track time down to 100 billionths of a second' as being 1/00th of a nanosecond, but on second reading and the article it is to the nearest 100ns.
As has been stated, PTP with supported hardware is achieving this - i've been working with it for a number of years and it's proven to be very good and very reliable, and ends up around 50ns within a rack, once your corrected for cable delays using a PPS feed.
So when the request came in to add a historic visualisation to the project, was this a new, out of the blue requirement, or was this always lurking as a nice to have feature that was hard, so had kept being pushed down the stack?
If it's a new out of the blue requirement, then there are millions of things that could have come along that would have been next to impossible to implement in the current system, but also, millions that would have fitted nicely (assuming there was some degree of thought and planning). The team should be able to push back on totally impossible to add features, and if that's not the case, then the company is not following any agile practice. You can't bolt it on at a team level and expect to see all the benefits. Turning it around, what sort of approach would allow any new requirement to be implementable?
Alternatively, it's been on the list of features and has kept been pushed back. This is then a team problem, and it's your responsibility to keep raising this. This is probably the most valuable part, getting visibility of the overall direction of a project, and being able to access and vocalise your concerns. If you didn't feel empowered to bring this stuff up, again, that's not agile.
So, badly implemented agile is a problem, as is badly implemented just about any process. Whether agile was the best fit for your project or for your company, that's a very different question, and agile is clearly not the right solution for everything, I've worked in plenty of secretive companies where agile is a problem as information is intentionally withheld from the developers, and this causes a massive mismatch which makes agile painful. If you company sees and understands these limitations, it can still work once you accept the inefficiencies.
Well, it does rather depend on which industry you work in - i've managed to find interesting programming jobs for 25 years, and there's no end in sight for interesting projects and new avenues to explore. However, this isn't for everyone, and if you have good personal skills then moving from programming into some technical management role is a very worthwhile route, and I know plenty of people who have found very interesting work in that direction.
That's what I felt when I first got a new MacBook Pro (I develop software for a client on it, so it's a requirement). Weirdly though, going back to the previous MacBook Pro with the previous generation keyboard that now feels very imprecise and wobbly by comparison.
It's odd what you get used to and start to feel is 'normal'.
Nah, there's little content in what you've said. Real programming languages? I'm going to guess that your real programming languages will keep changing over time to follow the current trend. When producing something long lived like an OS, you want to use established technologies where you know the implications and shortcomings, so something like C is a good place to start.
It sounds like they have loads of experience, but not practical skills for your current setup. Realistically if you were to train them to update their skills they would be just the same as any new (and potentially cheap) hire that you make - this isn't getting the best out of them.
No, what you want to do is take advantage of their experience. I'd be looking to shift their role, and only you can know what slots you have open, or where they may be able to contribute most. If they know everyone, then liasing between departments, IT and the users for example, may be good. They have probably got management skills which are under-utilised, and they will certainly be able to provide mentoring to new and inexperienced team members.
I'd start by talking your thinking through with them (individually) explaining the potential they have, and sounding out what they think they would like to do. You may find they have ideas which you haven't considered. If they want training up, then that is an option, but this is unlikely to be the best for the business.
Unless I've totally misunderstood the article, why isn't he telling people to move their projects from C to C++? Isn't the basic concept a better C, with give or take no surprises recompiling your C with a C++ compiler, and trickling in new language features which are applicable to your code base?
Of course, he could be lumping C and C++ together into one bucket, which to be honest, I tend to do but coming at it from the other direction (assuming you mean C++ when you say C). However, his mentions of what is wrong with C make me suspect he isn't. It's a bit of a major omission from the discussion if he isn't...
Now personally I rather like C++ as i'm writing realtime software, both soft and hard, and so I need to worry about and control memory allocation. False sharing is a concern, performance is critical (there's no upper limit to the required throughput, faster is always better for this code base). Until someone can offer an alternative, i'll be sticking to C++.
On a first quick read, it appears to be on about combining two separate streams into one, with the cameras looking in different directions (so basically multiplexing), not combining two camera images into a single image.
Slashdot Mirror
Oh, a bit of digging says that they are almost entirely hydroelectric production, so this is an actual real reduction in fossil fuel dependance. Awesome!
https://en.wikipedia.org/wiki/...
I'm guessing their grid has a fair bit of gas based electricity generation, so although the headline is nice, i'm waiting for their fossil fuel dependence to really drop to show what is possible.
You mean 3.5mm right? 1/4 inch, 3.5mm stereo, those are the two standards, but I take your point, and i'm happy to use my 3.5mm jack headphones every day. Works for me!
I'd be careful about calling something a fake when it's been tested in court. I imagine the intention is to portray that this Italian company has taken advantage of some weakness in an existing companies trade mark registration, which very well may be the case. A quick look on the web suggests the Italian outfit started off selling the products of the US company, before starting it's own product lines.
Personally if I produced a product and the only thing that differentiated it from another product available on the market was my use of my trademark on the front of the product, i'd really wonder what I was doing. This is a very recent idea in clothing, say 20-30 years old or so. Before then, the trademark would indicate quality, which appears to no longer be the case.
His parents did, and are monetising their son.
I think you need to grow up
Agreed. The simplest binary formats are very simple to store and retrieve, if you think about it, you just create a struct with non-pointer/reference types, and write your fields. Serialisation is a write of the memory to a file, deserialisation is a read. All in all, it'll be 10 lines of blindingly obvious code without any chance of programming errors, buffer overruns etc.
However, and this is a big however, it's completely inflexible, and has a number of massive downsides. It's going to be endian specific, it can't represent complex relationships between objects, it's not going to have any versioning support, the list goes on.
Once you start trying to address the above issues, you end up realising the problem is a bit larger than you thought, and end up re-creating something like google's Protocol Buffers, or Real Logic's Simple Binary Encoding, so you are better off using an established framework which then involves understanding how these work. At this point, you've kind of added back the complexity of the text based serialisation/deserialisation approach, so API wise it's not a great win. Performance wise though, something like SBE is leaps ahead of native serialisation if you don't need the flexibility that native serialisation supports (with it's polymorphism etc). Do check out SBE if you are wanting a lightish and performant mechanism, it's worked well for me (https://github.com/real-logic/simple-binary-encoding)
Seem to have gone a little away from the original point, apologies.
I'm not sure it applies across Europe either for that matter.
It's one of the only features I use on my feature phone. You could take out the cameras, GPS, motion sensors and probably half a dozen other bits i've never heard of let alone used, but the headphone socket is important to me.
If only I had an application that would be tractable on this sort of hardware. The ray tracing side of things is boring to me, i'd be interested to know how this works out for large matrix operations, or signal processing type applications. Still, more is more when it comes to compute!
The theoreticians don't come across as arrogant at all. To your point, the article specifically mentions that the emergent gravity theorists will need to work to resolve this issue, and that their work gives insights into other areas, and may be helpful for people doing other work (like quantum gravity). This in fact sounds deeply collaborative to me!
BTW, i'm not a theoretician, but i've spent a fair bit of time around various theoretical physicists, and the practical variety too, and they are to a person great to be around.
Agreed, the exact purpose is hazy. In europe we have the MiFID II requirements for trading systems and exchanges, and this is covered in RTS-25, which is here:
http://ec.europa.eu/finance/se...
I believe earlier drafts had timing requirements to the nanosecond until it was pointed out that a reference point was needed. The intention is to be able to track the order of events, and to put a requirement on exchanges, brokers and market participants to be able to provide audit information showing the order of events in their system to demonstrate that they are acting appropriately (so for example, not reordering order flows from clients to give preferential treatment to one client, or to themselves). How successful this is or will be is open, but the concept is a good one.
The article is pretty ambiguous - I originally read their claim that they ' track time down to 100 billionths of a second' as being 1/00th of a nanosecond, but on second reading and the article it is to the nearest 100ns.
As has been stated, PTP with supported hardware is achieving this - i've been working with it for a number of years and it's proven to be very good and very reliable, and ends up around 50ns within a rack, once your corrected for cable delays using a PPS feed.
So when the request came in to add a historic visualisation to the project, was this a new, out of the blue requirement, or was this always lurking as a nice to have feature that was hard, so had kept being pushed down the stack?
If it's a new out of the blue requirement, then there are millions of things that could have come along that would have been next to impossible to implement in the current system, but also, millions that would have fitted nicely (assuming there was some degree of thought and planning). The team should be able to push back on totally impossible to add features, and if that's not the case, then the company is not following any agile practice. You can't bolt it on at a team level and expect to see all the benefits. Turning it around, what sort of approach would allow any new requirement to be implementable?
Alternatively, it's been on the list of features and has kept been pushed back. This is then a team problem, and it's your responsibility to keep raising this. This is probably the most valuable part, getting visibility of the overall direction of a project, and being able to access and vocalise your concerns. If you didn't feel empowered to bring this stuff up, again, that's not agile.
So, badly implemented agile is a problem, as is badly implemented just about any process. Whether agile was the best fit for your project or for your company, that's a very different question, and agile is clearly not the right solution for everything, I've worked in plenty of secretive companies where agile is a problem as information is intentionally withheld from the developers, and this causes a massive mismatch which makes agile painful. If you company sees and understands these limitations, it can still work once you accept the inefficiencies.
Where I live, the car comes with plates and you never change them. In 25 years of car ownership i've never bought a licence plate for my cars.
Well, it does rather depend on which industry you work in - i've managed to find interesting programming jobs for 25 years, and there's no end in sight for interesting projects and new avenues to explore. However, this isn't for everyone, and if you have good personal skills then moving from programming into some technical management role is a very worthwhile route, and I know plenty of people who have found very interesting work in that direction.
That's what I felt when I first got a new MacBook Pro (I develop software for a client on it, so it's a requirement). Weirdly though, going back to the previous MacBook Pro with the previous generation keyboard that now feels very imprecise and wobbly by comparison.
It's odd what you get used to and start to feel is 'normal'.
Nah, there's little content in what you've said. Real programming languages? I'm going to guess that your real programming languages will keep changing over time to follow the current trend. When producing something long lived like an OS, you want to use established technologies where you know the implications and shortcomings, so something like C is a good place to start.
I see, having to post anonymously. Afraid of having your own opinions associated with you on a thread about freedom of speech?
I personally feel sorry for him - he has killed someone by mistake, and has to live with this for the rest of his life.
Given the level of incompetence exhibited by this government, i'd expect the bill to end up banning sales of all microphones.
It sounds like they have loads of experience, but not practical skills for your current setup. Realistically if you were to train them to update their skills they would be just the same as any new (and potentially cheap) hire that you make - this isn't getting the best out of them.
No, what you want to do is take advantage of their experience. I'd be looking to shift their role, and only you can know what slots you have open, or where they may be able to contribute most. If they know everyone, then liasing between departments, IT and the users for example, may be good. They have probably got management skills which are under-utilised, and they will certainly be able to provide mentoring to new and inexperienced team members.
I'd start by talking your thinking through with them (individually) explaining the potential they have, and sounding out what they think they would like to do. You may find they have ideas which you haven't considered. If they want training up, then that is an option, but this is unlikely to be the best for the business.
So if I were to write a straight 'hello world' app in these languages, it could be exploited. Any proof?
Unless I've totally misunderstood the article, why isn't he telling people to move their projects from C to C++? Isn't the basic concept a better C, with give or take no surprises recompiling your C with a C++ compiler, and trickling in new language features which are applicable to your code base?
Of course, he could be lumping C and C++ together into one bucket, which to be honest, I tend to do but coming at it from the other direction (assuming you mean C++ when you say C). However, his mentions of what is wrong with C make me suspect he isn't. It's a bit of a major omission from the discussion if he isn't...
Now personally I rather like C++ as i'm writing realtime software, both soft and hard, and so I need to worry about and control memory allocation. False sharing is a concern, performance is critical (there's no upper limit to the required throughput, faster is always better for this code base). Until someone can offer an alternative, i'll be sticking to C++.
On a first quick read, it appears to be on about combining two separate streams into one, with the cameras looking in different directions (so basically multiplexing), not combining two camera images into a single image.