Well it depends. I wrote a compact keylogger in assembly once to run on an MSDOS PC running Novell Netware (not password to catch otherwise). The fun thing was not coding it but how to hide it and its activity. It was loaded from AUTOEXEC.BAT IIRC but looked like (and replaced a) blank line by using character 255(?) which looks like but aren't treated like a blank space. It attached to the MSDOS routines so that it would only save the passwords when some other disk activity happened, it manipulated memory so that wouldn't be visible as a TSR when using the utilities of the day etc. The last change was to detect when the user logged out so it could be reactivated.
I consider that a hack. But not hacking/cracking as I never used it for something other than testing.
If so there have to be a continuous monitoring of song changes in order to trigger the recognition algorithm - and I'd call that continuous recognition.
Re-using boosters isn't game changing either. Its an improvement, but not a game changer.
What it so hard to understand? You may not agree (as game changing isn't precisely defined) but what the AC meant is pretty clear.
IMO game changing is e.g. the first functional ICBM when the opposition have "only" high altitude nuclear bombers. MIRV is a significant improvement but not game changing - but again you may think otherwise.
Liquid hydrogen is harder, sure. As in near impossible. It have a low energy density, it have to be stored at low temperatures ( the fuel tank would be _big_ which mean heavy and the extreme insulation needed will just add to the weight.
The thing here isn't that someone have switched to another liquid fuel - it is that they have succeeded in using LNG as the liquid fuel. If cheap* natural gas can do the work of a relatively expensive** RP1 fuel (as used by SpaceX and most other liquid fueled rockets) well then maybe that may be a significant advantage?
(* don't know how much processing have to be done to make it usable, it may not be cheap) (** significant processing => expensive)
So here I'm apparently trolling according to some. This when the one I responded to have _made_something_up_ in order to ridicule what _he_ responded to. Something that wasn't stated plain and clear nor implied. NB the post I responded to didn't even begin touching what _was_ written in the earlier post. Which was that the evidence is suspect and that we have more reasons to suspect US* software than Russian*. Orlanz didn't even reply to was stated by the previous post - what I would consider a trolling tactic.
And I'm trolling? If the PP are imagining things in the previous post _that_aren't_there_ isn't it a valid question to ask if that is something he experiences otherwise in daily life?
(* of course most software today aren't made in one country)
Depends on how common it is. Statistics to detect potential cheaters and then "simply" (with even more statistics) see if that potential cheater have to have external information or just being ridiculously lucky.
Wouldn't want to design the system but it's clearly possible.
With a common register file for architectural and speculative data.
The Fetch stage require the predicted next instruction (chunk) address and produces raw instruction data for the decoders. Decoders chops up instructions, identifies and extracts fields including register specifiers. The Rename stage allocates registers from the register file for all register writes and updates an internal remapping table so that later register reads will read from the relevant register file entry, in parallel all register reads in decoded instructions are looked up in the remapping table.
For reads: physical_register=remap[instruction_reg_field]
For writes: physical_register=allocate_physical_register() remap[instruction_reg_field]=physical_register
Later stages only use physical registers and not the instruction set defined ones.
Not having enough free registers would stall the pipeline, this is a bad thing. Solution: have enough physical registers that it's impossible or very unlikely to run out of physical registers.
Let's assume the conditional move is defined as:
CMOVE R_dest, R_src, R_cond
if (R_cond) R_dest = R_src;
Here my main objection should be clear: the renamer doesn't care about actual data, just register identifiers. To the renamer R_cond is just an architectural register identifier, not the data it contains or will contain in the future.
That is good as data is produced by the execution units several clocks below the rename logic in best case. In worst case the operation producing the condition to be checked can be stalled 100+ clocks waiting for external data.
Not only would allowing the renamer to snoop result data complicate the already expensive renaming logic, it would complicate bypass logic between execution units and would _still_ often stall when a CMOVE reaches the rename stage. Very expensive stalls.
1) The renamer doesn't have the data required for a conditional move.
This isn't unique. Instruction fetch have the same general problem, when a conditional branch instruction reaches the decode stage it doesn't in general have access to the condition it depends on. The solution is branch prediction, if the branch is likely to be taken (condition true) the front-end of the pipeline is speculatively redirected to fetch from the branch address otherwise it is ignored. If the prediction is later determined to be wrong all instructions and results resulting from that misprediction are undone.
2) Conditional moves in the renamer require speculation similar to a branch predictor.
But let's assume we handle a conditional move like a branch. IOW we use the branch predictor, we detect the CMOVE at decode and if the predictor says it is likely to be taken it is tagged so that the renamer can detect this and handle it appropriately. We could also use a dedicated predictor still tagging the CMOVE. That could be better.
What should the renamer do with a CMOVE? -- CMOVE Rd, Rs, Rc
Ps=remap[Rs] Pc=remap[Rc]
if (predictor_tag) remap[Rd]=Ps -- But we still have to have some way to check the prediction, that is: that Rc will get a value indicating a true condition in the future. Cleanest way is just allow the CMOVE to continue down the pipeline.
However there's still a problem remaining. One that also exist when doing non-conditional MOV elimination in the renamer like modern x86. We can have one physical register mapped to several architectural ones. This have to be tracked and handled. Worst case: 32 RISC registers can be mapped to one physical entry.
Again: Exactly how do you expect conditional moves to be executed at the renaming stage?
Cake walk? Sure the US can defeat NK but at significant costs. Unless using a significant amount of nuclear weapons that is - which would make the US a pariah at least and potentially lead to wars with other countries.
Really you have no fucking clue what you are talking about. The NK have a strong army of lesser quality than US forces but they have a _lot_ of trained soldiers that are ready to die for their country (if not their leader(s)). Quantity is a quality in itself.
You can visit them. They have diplomatic connections with several countries. They have trade agreements with several countries. A not insignificant number of people there get education abroad. They (as a country) have access to the Internet. They have radio broadcasts.
How could we tell? Blustering and aggressive bullshitting is the standard PR from NK. It's like trying to determine if someone is friendly when threatening to only rape you after you're dead...;)
As everything in NK data is hard to get by however they had dedicated much effort in developing their artillery. They use rocked augmented (assisted?) projectiles at least for the 170mm guns and IIRC use base-bleed designs for other sizes.
At least the 170mm guns can reach Seoul but not with any kind of precision. I'd think NK would concentrate fire on military objectives in general because while destroying Seoul may have strategic significance tactical flexibility may be what decides if the state will survive.
Slashdot Mirror
Well it depends. I wrote a compact keylogger in assembly once to run on an MSDOS PC running Novell Netware (not password to catch otherwise). The fun thing was not coding it but how to hide it and its activity. It was loaded from AUTOEXEC.BAT IIRC but looked like (and replaced a) blank line by using character 255(?) which looks like but aren't treated like a blank space. It attached to the MSDOS routines so that it would only save the passwords when some other disk activity happened, it manipulated memory so that wouldn't be visible as a TSR when using the utilities of the day etc.
The last change was to detect when the user logged out so it could be reactivated.
I consider that a hack. But not hacking/cracking as I never used it for something other than testing.
Cool idea but probably hard to make work... Probably, there are a lot of smart people.
If so there have to be a continuous monitoring of song changes in order to trigger the recognition algorithm - and I'd call that continuous recognition.
This is basic logic.
Well there are plenty of songs that start with silence... ;P
Blue origin != SpaceX.
Re-using boosters isn't game changing either. Its an improvement, but not a game changer.
What it so hard to understand? You may not agree (as game changing isn't precisely defined) but what the AC meant is pretty clear.
IMO game changing is e.g. the first functional ICBM when the opposition have "only" high altitude nuclear bombers. MIRV is a significant improvement but not game changing - but again you may think otherwise.
Liquid hydrogen is harder, sure. As in near impossible. It have a low energy density, it have to be stored at low temperatures ( the fuel tank would be _big_ which mean heavy and the extreme insulation needed will just add to the weight.
The thing here isn't that someone have switched to another liquid fuel - it is that they have succeeded in using LNG as the liquid fuel. If cheap* natural gas can do the work of a relatively expensive** RP1 fuel (as used by SpaceX and most other liquid fueled rockets) well then maybe that may be a significant advantage?
(* don't know how much processing have to be done to make it usable, it may not be cheap)
(** significant processing => expensive)
So here I'm apparently trolling according to some.
This when the one I responded to have _made_something_up_ in order to ridicule what _he_ responded to. Something that wasn't stated plain and clear nor implied.
NB the post I responded to didn't even begin touching what _was_ written in the earlier post. Which was that the evidence is suspect and that we have more reasons to suspect US* software than Russian*. Orlanz didn't even reply to was stated by the previous post - what I would consider a trolling tactic.
And I'm trolling? If the PP are imagining things in the previous post _that_aren't_there_ isn't it a valid question to ask if that is something he experiences otherwise in daily life?
(* of course most software today aren't made in one country)
It's an example of you not understanding. Brute forcing is (generally) impossible and that's not what this is about.
Are you imagining voices in your head too?
This just in: everything honest and pure have to have a web presence! Anti-Internet is the work of the DEVIL*!
(* or your religion/worldview equivalent, mine is the neighbor upstairs - damn him and his non-disturbing manners!)
Deep inside we all are.
I know it just doesn't make sense. That's okay, I've never seen any ideological fantasy that makes sense when applied to the real world.
Oh, and the writing is crap. I'd rather read Das Kapital in the original German (which would be pure torture BTW).
Yes but every rule has an exception.
Depends on how common it is. Statistics to detect potential cheaters and then "simply" (with even more statistics) see if that potential cheater have to have external information or just being ridiculously lucky.
Wouldn't want to design the system but it's clearly possible.
A bad keyboard is still better than a touchscreen for almost any use. Well, finger-painting is better with the touchscreen.
The common design for a high-performance OoO core today is something like this:
(Warning! Very simplified!)
Fetch - Decode - Rename - Schedule - Execute - Retire
With a common register file for architectural and speculative data.
The Fetch stage require the predicted next instruction (chunk) address and produces raw instruction data for the decoders.
Decoders chops up instructions, identifies and extracts fields including register specifiers.
The Rename stage allocates registers from the register file for all register writes and updates an internal remapping table so that later register reads will read from the relevant register file entry, in parallel all register reads in decoded instructions are looked up in the remapping table.
For reads:
physical_register=remap[instruction_reg_field]
For writes:
physical_register=allocate_physical_register()
remap[instruction_reg_field]=physical_register
Later stages only use physical registers and not the instruction set defined ones.
Not having enough free registers would stall the pipeline, this is a bad thing. Solution: have enough physical registers that it's impossible or very unlikely to run out of physical registers.
Let's assume the conditional move is defined as:
CMOVE R_dest, R_src, R_cond
if (R_cond) R_dest = R_src;
Here my main objection should be clear: the renamer doesn't care about actual data, just register identifiers. To the renamer R_cond is just an architectural register identifier, not the data it contains or will contain in the future.
That is good as data is produced by the execution units several clocks below the rename logic in best case. In worst case the operation producing the condition to be checked can be stalled 100+ clocks waiting for external data.
Not only would allowing the renamer to snoop result data complicate the already expensive renaming logic, it would complicate bypass logic between execution units and would _still_ often stall when a CMOVE reaches the rename stage. Very expensive stalls.
1) The renamer doesn't have the data required for a conditional move.
This isn't unique. Instruction fetch have the same general problem, when a conditional branch instruction reaches the decode stage it doesn't in general have access to the condition it depends on. The solution is branch prediction, if the branch is likely to be taken (condition true) the front-end of the pipeline is speculatively redirected to fetch from the branch address otherwise it is ignored. If the prediction is later determined to be wrong all instructions and results resulting from that misprediction are undone.
2) Conditional moves in the renamer require speculation similar to a branch predictor.
But let's assume we handle a conditional move like a branch. IOW we use the branch predictor, we detect the CMOVE at decode and if the predictor says it is likely to be taken it is tagged so that the renamer can detect this and handle it appropriately.
We could also use a dedicated predictor still tagging the CMOVE. That could be better.
What should the renamer do with a CMOVE?
--
CMOVE Rd, Rs, Rc
Ps=remap[Rs]
Pc=remap[Rc]
if (predictor_tag) remap[Rd]=Ps
--
But we still have to have some way to check the prediction, that is: that Rc will get a value indicating a true condition in the future. Cleanest way is just allow the CMOVE to continue down the pipeline.
However there's still a problem remaining. One that also exist when doing non-conditional MOV elimination in the renamer like modern x86.
We can have one physical register mapped to several architectural ones. This have to be tracked and handled. Worst case: 32 RISC registers can be mapped to one physical entry.
Again: Exactly how do you expect conditional moves to be executed at the renaming stage?
You are an idiot. Luckily the SK/US armies aren't.
Cake walk? Sure the US can defeat NK but at significant costs. Unless using a significant amount of nuclear weapons that is - which would make the US a pariah at least and potentially lead to wars with other countries.
Really you have no fucking clue what you are talking about. The NK have a strong army of lesser quality than US forces but they have a _lot_ of trained soldiers that are ready to die for their country (if not their leader(s)). Quantity is a quality in itself.
You can visit them. They have diplomatic connections with several countries. They have trade agreements with several countries. A not insignificant number of people there get education abroad. They (as a country) have access to the Internet. They have radio broadcasts.
Yes it's mostly one-way but they aren't isolated.
How could we tell? Blustering and aggressive bullshitting is the standard PR from NK. It's like trying to determine if someone is friendly when threatening to only rape you after you're dead... ;)
NK know well that there are several current decapitation plans - because that's obvious unless the SK military/politicians were absolute incompetent!
The US probably have plans how to invade Switzerland if it would ever come to that, just as they had plans to nuke Finland.
As everything in NK data is hard to get by however they had dedicated much effort in developing their artillery. They use rocked augmented (assisted?) projectiles at least for the 170mm guns and IIRC use base-bleed designs for other sizes.
At least the 170mm guns can reach Seoul but not with any kind of precision. I'd think NK would concentrate fire on military objectives in general because while destroying Seoul may have strategic significance tactical flexibility may be what decides if the state will survive.
Not a military freak/geek so YMMV.
Substance induced psychosis is a thing, so yes.
Nor do Belgians.