It fells to me this is just telling you that the malware writers aren't targeting bypassing edge, and are concentrating on chrome. If edge had a larger user base, and was worth attacking, then the ways around the blocking of malware would be found, and we'd see a change in these stats.
I can imagine lots of situations where what you say is correct, but i've also come across (and mainly work) in situations where this would be totally over the top, and wasted effort.
As an example, i've written tonnes of software that is only ever used once - you know the stuff, the 'load this dataset into the database' type task which is basically a bit of scripting, takes an hour or two, is run once, and is then thrown away. It might not even make it into source control. How about those ad-hoc queries you produce to answer a management query - 'what sort of data rates have we had to deal with historically' or whatever.
How about your bash profile? You got any documentation for it? Those helper scripts to wrap some confusing build/test cycle commands that you need?
So I would be careful with any catch-all thinking about documentation, certainly in the software field. I've dealt with various supplied APIs from external suppliers with excellent documentation, and i'm currently working with one with horrendous documentation, and I know which i'd rather have!
Assuming it has to gather light, i'd be very surprised if the sensor will collect enough info in a millionth of a second to get any idea what I look like. I'd also be surprised if a few thousand clock cycles is enough computation to decide if I am who I am.
If I wanted a quick unlock mechanism, i'd go with some sort of RFID in a wrist band that if you are wearing would allow the unlock without pin, as this seems pretty simple understandable technology which is already available.
Agreed, i've worked places where stuff like this is possible.
Remember, if the place was a windows shop, and the DB is, say, SQL Server, then the permissions to do dangerous stuff may just be group membership of the user account in AD, so you could get production read/write access without typing a password, just by connecting to a db server.
I've worked on linux systems where the production access is locked to a given user, but it was common to sudo to this user for certain tasks. If the user in question isn't called 'prod' or something like that, but say, named after the product, it's not clear what permissions, and in fact, damage you can do.
So yes, it's possible, and i've been places where this can happen. Actually, sitting at my desk at work, I can screw the system in many ways without typing a password. I can delete binaries, or promote something broken to production, or screw up network configuration, or well, just endless ways really. The upside is that I can fix stuff quickly when it goes wrong, and each company needs to evaluate the risk vs reward tradeoff to determine what is right for them. When the stuff I produce goes wrong, only the company is harmed, and they have no external users who would be aware. If I were working on some web facing system with millions of users, clearly a different approach is appropriate!
A report I read suggested they had around 500 cabinets of machines (not sure if this was across both sites or the primary). Estimating 2KW/cabinet brings you into MW territory for the lot, so this is a non-trivial amount of machinery to keep running in a power failure situation. The failure description suggested that it was a surge issue, so it's not clear if this was just stupids on their behalf (not staggering restart) or something else going wrong within the site (bad failure to generators etc).
Either way, their IT infrastructure wasn't up to the job, and clearly their DR planning didn't get them out of the hole quickly. However, their DR planning did get them running again within a few days which is more than most companies can manage. Well done to the guys actually doing the work - lots of long shifts and stress, and let's hope they get traction with management to put some decent process in place for the future.
Nonsense. Excel is an excellent tool when used for it's main purpose, which is as a spreadsheet (obviously). The moment you start hacking VB into it, and connecting to remote data sources, you're way off the sensible path. As a viewer on ad-hoc generated reports from things like accounting packages, it's great, and that's what businesses tend to do with it these days.
If I were to complain about excel, it would be some of the daft csv import logic which means that dates and times aren't parsed in a sensible manner, and the most ludicrous restriction meaning you can't open two docs with the same name (can't believe this is still an issue).
Well I make prints without ink - I have a darkroom so make traditional B&W silver prints. The 'specially treated paper' I use costs less per page than fancy paper for an inkjet printer.
For example, I can get Ilford RC paper in 12*16 inches for £1 per page (£50 for 50 sheets), whilst ilford galerie prestige A3 sheets cost £1.70 per page (£44 for 25 sheets). The 'ink' equivalent is included in the paper for darkroom printing, so there are no additional running costs for making a print, other than developer and fix, which cost pennies per page, so little it's really not worth worrying about. I would probably use 5p of chemistry to make an A3 print.
To add to this, my enlarger can print as big as I want, and I can get paper in much larger sizes - I am not restricted to the width of the paper feed that the printer decides it supports. I have a 30m roll of paper which is 120cm wide, for example.
So no, there is prior art to printing big onto fancy paper which ends up being cheaper than just plain paper - i'm not saying this technique will, but don't rule it out.
BTW, if you were wondering, Fuji Crystal archive paper is a colour paper, and costs less than B&W paper (£40 for 50 A3 sheets), but the chemistry is more expensive, and doesn't last well, but again, it ends up much cheaper than inkjet printing. I don't do much of this, it's a right faff, but others do.
I worked with a Bangalore based Indian development team in the late 90s, and they were a very competent bunch of developers. They were typically older than the equivalent UK team (early 30s was the average for them), but the only criticism I had was that they tended to take as read that what was suggested as a solution would work, which lead to lots of wasted time chasing down blind alleys. Once they got the hang of the software stack they were working with, and understood they had greater say and control over how things were achieved, they produced great code.
So, I imagine, it's like most things in life, that gross generalisations don't tell you much.
Agreed. The field is just too large for people to have *any* chance of keeping a useful handle on what is going on. You are going to have to specialise. The trick I think is to know what you don't know, not to keep up with everything. I was recently asked by a potential client if I could produce a mobile phone app for them - 'no chance, i'm not competent at that' was my reply. I pointed them at someone who specialises in this work. Knowing what you don't know (and who does!) is a much more useful skill than attempting to keep up with everything...
Actually, no, what lots of us do is solve real world business problems by automating them using computers. Knowing what the business problem is is just as valuable as understanding how computers work, and you can approach the solution from either direction - neither is implicitly better than the other.
BTW, I'm a CompSci, but I work with Physics Phd types who understand the problems I work on better than I ever will, and we have complementary skills.
It has always interested me to know what drives companies to upgrade their systems. Let's say you have a farm of 1,000 servers that you've had for 5 years, doing useful stuff, running 12.04 - what incentive is there for you to upgrade?
If they are web facing, and under attack - sure, I get it. If you are developing cutting edge software for deployment to other hosts - I get it.
But if you are using them to actually do work for your company, say, running some data mining, or hosting a big kafka cluster, why change? The logical point is when you rip the lot out and install new hardware (and decide on a new machine config, including OS) but for existing hardware, shouldn't the OS choice live for the life of the server?
Well, it's might introduce latency, or it might not, it really does depend on exactly how it's all setup.
I can imagine VS working on a shared filesystem, so that sshing and invoking the build (probably via cmake as cmake support is new in VS2017) is pretty quick and painless if the machine is nearby. If it runs the build, and integrates build/test results with the IDE, then it's going to be a performance win for some people who are very VS centric, and who are developing cross platform libraries.
Anything that reduces the pain of cross platform development is welcome - it's not easy to do well, and you really don't want to be switching between multiple toolchains too much as it'll make your brain hurt. Each additional platform takes much extra effort, and keeping that number in check will really help.
HP DL370 - industry standard 2S Xeon socket server HP DL570 - industry standard 4S Xeon socket server
Sure, getting hold of a mass produced 4S motherboard is difficult, and these 4S servers aren't cheap but if you are intending on buying $20k of processors to run on it, the difficulties can also be solved by throwing money at the problem.
I'm not sure what world you are living in, but in the one i'm in, we have CPUs with a lot more cores the 4, 6 or 8.
For starters, mainstream Intel dual socket supporting processors have 22 core options - E5-4669 v4 for example. So, you can get 44 cores into a dual socket machine.
Sun/Oracle got into this game in a big way with their T series processors, and blurred threads vs cores (in a very interesting way), so produce things like the T5 with 16 cores and 128 threads - it's like hyperthreading, but very cleverly done, so instead of relying on out of order execution to keep the execution units humming, you use multiple threads. Of course you can get multi-socket machines for these too, so you can get a T5-8, so 8 sockets (128 cores, 1024 threads).
So, high core count is out there, you just jave to look a little further than intel processors aimed at the desktop market.
Actually, svn is just about the perfect source control system if you want something quick and dirty that you can understand. git (I presume that is what you would propose as an alternative) adds no features to many small software development teams. Fortunately the svn->git migration path is well trodden.
If you had mentioned cvs, or rcs, then i'd agree;-)
The Z600 and Z620 are a real joy to use and sit by - they are full of low speed fans, and sensible airflow design, so you can get a dual xeon in an under-desk format and these would be my preference. I've actually got one of each, the Z620 is my normal desktop machine, with dual E5-2670, and 48gb of RAM. It has plenty of CPU and RAM to throw at VMs. The Z600 I have has X5650 processors in it, so it's dual six core, and plenty fast enough.
The DL 380s, G6/G7/G8 are not silent, and you'd get annoyed if you tried to live with one next to you all day. The fans get loud and blowy, but can be set to throttle back. The iLO stuff allows you to remote power cycle these servers, and check their overall happiness. This means that remote operation is much more manageable. I've got 4 (two G6s and two G7s) in my loft, and they are great, doing both CI duty, and two as a test platform for some performance benchmarking. Power use is around 80-100 watts per server, but this is as I have them throttling back to conserve power as they are for development, and normally one is on, and the others I power up when I need them.
So if you have space, DL380s are great, but if you want to sit next to it all day, go Z600/Z620.
My preferred choice of machines from that era would be the HP Z600 and Z620 - dual socket capable machines, taking X5600 series in the case of the Z600, and E5 and E5 v2 processors in the Z620 (v2 only if it's the later BIOS version).
Here in the UK, the Z600 with dual 6 core processors can be picked up with relative ease, and these work well. The Z620 can be harder to find, but can run with dual 8 core processors (say, E5-2670) or dual 10 core processors (E5-2670 v2). The v2s are still very expensive on the second hand market, so stick with an E5 for now. Both machines take heaps of standard DDR3 registered ram, so it's easy to come by.
If you want rack mount, get an HP-DL380, say a G7, or a G8. The G7s are very cheap these days, whilst the G8 tend to hold their value a bit more. Again, dual socket boards, so you get lots of CPU and plenty of DDR3 slots in them.
If you worry that you're going to miss out with the slower ram that these machines use, then you're doing it wrong - get your working set down into L3 cache (20mb or so), that'd be my advice;-)
Realistically what is going on here is that china has started investing in this area, as it has massively behind - the US and Europe are miles ahead, and China aren't even on the radar. I'd suggest London is the centre for development, whilst the US provides the hardware expertise. I'm pretty certain i've not worked with any Chinese kit over the years in trading systems, and i'd be surprised if this became common for various reasons (and let's face it, security concerns would be on the list).
Indeed, a successful model. The right team mix with the right level of experience and enthusiasm can really churn through the work and get stuff sorted. Team of 8 where I am - 4 under 25, 2 mid 30s, two over 45. The trick is to understand what everyone brings to the team (invariably different skills), and to totally ignore upper managements belief that everyone is equally capable and interested in tackling every problem (you're all developers right?).
C is a small language, certainly compared to the others in the top of the list (Java and Python libraries are just huge). By using postings and general 'chat' about languages to gauge interest, i'm a little worried that people attempting to get their head around the larger language libraries will be taken as equivalent to what will most likely be more targeted chat about C. To me this would suggest that C is probably underscored, whilst larger languages will be overscored if using this sort of approach (not that i've dug properly into their methodology!).
Slashdot Mirror
It fells to me this is just telling you that the malware writers aren't targeting bypassing edge, and are concentrating on chrome. If edge had a larger user base, and was worth attacking, then the ways around the blocking of malware would be found, and we'd see a change in these stats.
I can imagine lots of situations where what you say is correct, but i've also come across (and mainly work) in situations where this would be totally over the top, and wasted effort.
As an example, i've written tonnes of software that is only ever used once - you know the stuff, the 'load this dataset into the database' type task which is basically a bit of scripting, takes an hour or two, is run once, and is then thrown away. It might not even make it into source control. How about those ad-hoc queries you produce to answer a management query - 'what sort of data rates have we had to deal with historically' or whatever.
How about your bash profile? You got any documentation for it? Those helper scripts to wrap some confusing build/test cycle commands that you need?
So I would be careful with any catch-all thinking about documentation, certainly in the software field. I've dealt with various supplied APIs from external suppliers with excellent documentation, and i'm currently working with one with horrendous documentation, and I know which i'd rather have!
Assuming it has to gather light, i'd be very surprised if the sensor will collect enough info in a millionth of a second to get any idea what I look like. I'd also be surprised if a few thousand clock cycles is enough computation to decide if I am who I am.
If I wanted a quick unlock mechanism, i'd go with some sort of RFID in a wrist band that if you are wearing would allow the unlock without pin, as this seems pretty simple understandable technology which is already available.
Nope, just looks like a bug to me. They may even have a typedef/using, it could be a one liner to fix.
Agreed, i've worked places where stuff like this is possible.
Remember, if the place was a windows shop, and the DB is, say, SQL Server, then the permissions to do dangerous stuff may just be group membership of the user account in AD, so you could get production read/write access without typing a password, just by connecting to a db server.
I've worked on linux systems where the production access is locked to a given user, but it was common to sudo to this user for certain tasks. If the user in question isn't called 'prod' or something like that, but say, named after the product, it's not clear what permissions, and in fact, damage you can do.
So yes, it's possible, and i've been places where this can happen. Actually, sitting at my desk at work, I can screw the system in many ways without typing a password. I can delete binaries, or promote something broken to production, or screw up network configuration, or well, just endless ways really. The upside is that I can fix stuff quickly when it goes wrong, and each company needs to evaluate the risk vs reward tradeoff to determine what is right for them. When the stuff I produce goes wrong, only the company is harmed, and they have no external users who would be aware. If I were working on some web facing system with millions of users, clearly a different approach is appropriate!
A report I read suggested they had around 500 cabinets of machines (not sure if this was across both sites or the primary). Estimating 2KW/cabinet brings you into MW territory for the lot, so this is a non-trivial amount of machinery to keep running in a power failure situation. The failure description suggested that it was a surge issue, so it's not clear if this was just stupids on their behalf (not staggering restart) or something else going wrong within the site (bad failure to generators etc).
Either way, their IT infrastructure wasn't up to the job, and clearly their DR planning didn't get them out of the hole quickly. However, their DR planning did get them running again within a few days which is more than most companies can manage. Well done to the guys actually doing the work - lots of long shifts and stress, and let's hope they get traction with management to put some decent process in place for the future.
Nonsense. Excel is an excellent tool when used for it's main purpose, which is as a spreadsheet (obviously). The moment you start hacking VB into it, and connecting to remote data sources, you're way off the sensible path. As a viewer on ad-hoc generated reports from things like accounting packages, it's great, and that's what businesses tend to do with it these days.
If I were to complain about excel, it would be some of the daft csv import logic which means that dates and times aren't parsed in a sensible manner, and the most ludicrous restriction meaning you can't open two docs with the same name (can't believe this is still an issue).
Well I make prints without ink - I have a darkroom so make traditional B&W silver prints. The 'specially treated paper' I use costs less per page than fancy paper for an inkjet printer.
For example, I can get Ilford RC paper in 12*16 inches for £1 per page (£50 for 50 sheets), whilst ilford galerie prestige A3 sheets cost £1.70 per page (£44 for 25 sheets). The 'ink' equivalent is included in the paper for darkroom printing, so there are no additional running costs for making a print, other than developer and fix, which cost pennies per page, so little it's really not worth worrying about. I would probably use 5p of chemistry to make an A3 print.
To add to this, my enlarger can print as big as I want, and I can get paper in much larger sizes - I am not restricted to the width of the paper feed that the printer decides it supports. I have a 30m roll of paper which is 120cm wide, for example.
So no, there is prior art to printing big onto fancy paper which ends up being cheaper than just plain paper - i'm not saying this technique will, but don't rule it out.
BTW, if you were wondering, Fuji Crystal archive paper is a colour paper, and costs less than B&W paper (£40 for 50 A3 sheets), but the chemistry is more expensive, and doesn't last well, but again, it ends up much cheaper than inkjet printing. I don't do much of this, it's a right faff, but others do.
I worked with a Bangalore based Indian development team in the late 90s, and they were a very competent bunch of developers. They were typically older than the equivalent UK team (early 30s was the average for them), but the only criticism I had was that they tended to take as read that what was suggested as a solution would work, which lead to lots of wasted time chasing down blind alleys. Once they got the hang of the software stack they were working with, and understood they had greater say and control over how things were achieved, they produced great code.
So, I imagine, it's like most things in life, that gross generalisations don't tell you much.
Yeah, agreed.
Agreed. The field is just too large for people to have *any* chance of keeping a useful handle on what is going on. You are going to have to specialise. The trick I think is to know what you don't know, not to keep up with everything. I was recently asked by a potential client if I could produce a mobile phone app for them - 'no chance, i'm not competent at that' was my reply. I pointed them at someone who specialises in this work. Knowing what you don't know (and who does!) is a much more useful skill than attempting to keep up with everything...
Actually, no, what lots of us do is solve real world business problems by automating them using computers. Knowing what the business problem is is just as valuable as understanding how computers work, and you can approach the solution from either direction - neither is implicitly better than the other.
BTW, I'm a CompSci, but I work with Physics Phd types who understand the problems I work on better than I ever will, and we have complementary skills.
It has always interested me to know what drives companies to upgrade their systems. Let's say you have a farm of 1,000 servers that you've had for 5 years, doing useful stuff, running 12.04 - what incentive is there for you to upgrade?
If they are web facing, and under attack - sure, I get it.
If you are developing cutting edge software for deployment to other hosts - I get it.
But if you are using them to actually do work for your company, say, running some data mining, or hosting a big kafka cluster, why change? The logical point is when you rip the lot out and install new hardware (and decide on a new machine config, including OS) but for existing hardware, shouldn't the OS choice live for the life of the server?
Well, it's might introduce latency, or it might not, it really does depend on exactly how it's all setup.
I can imagine VS working on a shared filesystem, so that sshing and invoking the build (probably via cmake as cmake support is new in VS2017) is pretty quick and painless if the machine is nearby. If it runs the build, and integrates build/test results with the IDE, then it's going to be a performance win for some people who are very VS centric, and who are developing cross platform libraries.
Anything that reduces the pain of cross platform development is welcome - it's not easy to do well, and you really don't want to be switching between multiple toolchains too much as it'll make your brain hurt. Each additional platform takes much extra effort, and keeping that number in check will really help.
HP DL370 - industry standard 2S Xeon socket server
HP DL570 - industry standard 4S Xeon socket server
Sure, getting hold of a mass produced 4S motherboard is difficult, and these 4S servers aren't cheap but if you are intending on buying $20k of processors to run on it, the difficulties can also be solved by throwing money at the problem.
I'm not sure what world you are living in, but in the one i'm in, we have CPUs with a lot more cores the 4, 6 or 8.
For starters, mainstream Intel dual socket supporting processors have 22 core options - E5-4669 v4 for example. So, you can get 44 cores into a dual socket machine.
Sun/Oracle got into this game in a big way with their T series processors, and blurred threads vs cores (in a very interesting way), so produce things like the T5 with 16 cores and 128 threads - it's like hyperthreading, but very cleverly done, so instead of relying on out of order execution to keep the execution units humming, you use multiple threads. Of course you can get multi-socket machines for these too, so you can get a T5-8, so 8 sockets (128 cores, 1024 threads).
So, high core count is out there, you just jave to look a little further than intel processors aimed at the desktop market.
Actually, svn is just about the perfect source control system if you want something quick and dirty that you can understand. git (I presume that is what you would propose as an alternative) adds no features to many small software development teams. Fortunately the svn->git migration path is well trodden.
If you had mentioned cvs, or rcs, then i'd agree ;-)
The Z600 and Z620 are a real joy to use and sit by - they are full of low speed fans, and sensible airflow design, so you can get a dual xeon in an under-desk format and these would be my preference. I've actually got one of each, the Z620 is my normal desktop machine, with dual E5-2670, and 48gb of RAM. It has plenty of CPU and RAM to throw at VMs. The Z600 I have has X5650 processors in it, so it's dual six core, and plenty fast enough.
The DL 380s, G6/G7/G8 are not silent, and you'd get annoyed if you tried to live with one next to you all day. The fans get loud and blowy, but can be set to throttle back. The iLO stuff allows you to remote power cycle these servers, and check their overall happiness. This means that remote operation is much more manageable. I've got 4 (two G6s and two G7s) in my loft, and they are great, doing both CI duty, and two as a test platform for some performance benchmarking. Power use is around 80-100 watts per server, but this is as I have them throttling back to conserve power as they are for development, and normally one is on, and the others I power up when I need them.
So if you have space, DL380s are great, but if you want to sit next to it all day, go Z600/Z620.
My preferred choice of machines from that era would be the HP Z600 and Z620 - dual socket capable machines, taking X5600 series in the case of the Z600, and E5 and E5 v2 processors in the Z620 (v2 only if it's the later BIOS version).
Here in the UK, the Z600 with dual 6 core processors can be picked up with relative ease, and these work well. The Z620 can be harder to find, but can run with dual 8 core processors (say, E5-2670) or dual 10 core processors (E5-2670 v2). The v2s are still very expensive on the second hand market, so stick with an E5 for now. Both machines take heaps of standard DDR3 registered ram, so it's easy to come by.
If you want rack mount, get an HP-DL380, say a G7, or a G8. The G7s are very cheap these days, whilst the G8 tend to hold their value a bit more. Again, dual socket boards, so you get lots of CPU and plenty of DDR3 slots in them.
If you worry that you're going to miss out with the slower ram that these machines use, then you're doing it wrong - get your working set down into L3 cache (20mb or so), that'd be my advice ;-)
Realistically what is going on here is that china has started investing in this area, as it has massively behind - the US and Europe are miles ahead, and China aren't even on the radar. I'd suggest London is the centre for development, whilst the US provides the hardware expertise. I'm pretty certain i've not worked with any Chinese kit over the years in trading systems, and i'd be surprised if this became common for various reasons (and let's face it, security concerns would be on the list).
Well I believe them, it will be encrypted before it leaves your machine. The real question is who will have the key.
Indeed, a successful model. The right team mix with the right level of experience and enthusiasm can really churn through the work and get stuff sorted. Team of 8 where I am - 4 under 25, 2 mid 30s, two over 45. The trick is to understand what everyone brings to the team (invariably different skills), and to totally ignore upper managements belief that everyone is equally capable and interested in tackling every problem (you're all developers right?).
C is a small language, certainly compared to the others in the top of the list (Java and Python libraries are just huge). By using postings and general 'chat' about languages to gauge interest, i'm a little worried that people attempting to get their head around the larger language libraries will be taken as equivalent to what will most likely be more targeted chat about C. To me this would suggest that C is probably underscored, whilst larger languages will be overscored if using this sort of approach (not that i've dug properly into their methodology!).
Sounds rather confusing then.
So please explain what the expected behaviour of cron is? Do my jobs start only if i'm logged in - is that the idea, or is cron 'an exception'?